I have tried this with several different databases on different machines running both Win XP Home and Windows 7. The results are consistently as follows: 1. Open an existing database. 2. Open a form. 3. Click on the "Find Record" button on the bottom left. The result: A crash with the following error message: """"" Runtime Error! Program: C:\Program Files\LibreOffice 3.4\program\soffice.bin This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. """"" This makes Base essentially useless, since one of the major uses of a database is to be able to search for data.
I'm non able to reproduce this crash. Cloud you please attach a sample document?
Hi Steve, Sorry, but this works for me on Mac OSX with 3.4.3, so I can not reproduce the crash. I suspect you may have a corrupt user configuration or else the problem is Windows specific. Alex
I use windows, and it works for me. A sample document will be useful.
(In reply to comment #3) > I use windows, and it works for me. A sample document will be useful. So more than likely an environment specific behaviour, i.e. corrupt LibO user configuration data. This is know to have happened when switching from certain 3.3.x versions to a 3.4.x version for example. Alex
Created attachment 50981 [details] Database that crashes when "Find Record" is clicked Attached is one of the databases that I notice this problem with. I should note that I was able to open a different database this morning and it worked with no trouble, but that is the only database I have been able to make work, and it is an extremely simple database with only one table and one form. The rest of the databases I've tried experience the same errors as the one I have attached.
I confirm the crash with LibO 3.4.3 under Win7. No crash with LibO 3.3.x -> Regression
Confirming on Mac OSX too with 3.4.3, the crash occurs as soon as I click on the binocular icon representing the search function. The problem is therefore linked to the specifics of the file, so the next step is to go through the file and try and find out what exactly causes this to happen. First thoughts are the number of relations : I had a look at the relations design and see that there are quite a few, but I didn't check the details of how each was set up. It may be that there is something in there that the search function can't handle and thus causes LibO to die. Oh, nice little db by the way Steve - my curiosity is more than piqued, looks like a practice docket management db ? Alex
changed platform to all. Alex
We ought to flag this as a blocker for future 3.4 releases. Let me try it out in a 3.5 build too, perhaps the problem has gone away there. Alex
(In reply to comment #6) > I confirm the crash with LibO 3.4.3 under Win7. No crash with LibO 3.3.x -> > Regression LOL, you were just too quick for me :-) Alex
Created attachment 50987 [details] mac osx crash trace - search function in ODB
FWIW, I can't get this to crash when I open the other forms, i.e. only the first form in the list of forms, "Case Details", is the source of the crash, so there is something particular about the structure of this form that triggers it. Alex
Alex: Yes, it's a practice management database for my law firm. This is actually a "stand-alone" version that I'm currently testing with a few other attorneys who are in solo practice. (It's a lot cheaper than Time Matters or Needles, that's for sure!)
(In reply to comment #13) > Alex: Yes, it's a practice management database for my law firm. This is > actually a "stand-alone" version that I'm currently testing with a few other > attorneys who are in solo practice. (It's a lot cheaper than Time Matters or > Needles, that's for sure!) Well, it is very interesting for me too as a solo IP attorney - I realize that it is US focussed, whereas I operate in Europe (France), and so my needs are slightly different, but it could be of use to me too, with a few changes :-))
Reproduced on GNU/Linux amd64. This failed assertion looks relevant: Error: FmXFormShell::OnSearchContextRequest : impossible : have more view than model columns ! From File /home/master/src/libreoffice/libreoffice-3.4/svx/source/form/fmshimp.cxx at Line 2491 Log of FmXGridPeer::getByIndex calls: FmXGridPeer::getByIndex (this=0x250efa0, _nIndex=0) FmXGridPeer::getByIndex (this=0x250efa0, _nIndex=1) Error: FmXFormShell::OnSearchContextRequest : impossible : have more view than model columns ! From File /home/master/src/libreoffice/libreoffice-3.4/svx/source/form/fmshimp.cxx at Line 2491 FmXGridPeer::getByIndex (this=0x2594660, _nIndex=0) and in this call, we get the error. Backtrace of that last call: #0 FmXGridPeer::getByIndex (this=0x2594660, _nIndex=0) at /home/master/src/libreoffice/libreoffice-3.4/svx/source/fmcomp/fmgridif.cxx:2434 #1 0x00007fffd8bb3759 in FmXFormShell::OnSearchContextRequest (this=0x2464720, pfmscContextInfo=0x7fffffff9280) at /home/master/src/libreoffice/libreoffice-3.4/svx/source/form/fmshimp.cxx:2496 #2 0x00007fffd8bad6e0 in FmXFormShell::ExecuteSearch (this=0x2464720) at /home/master/src/libreoffice/libreoffice-3.4/svx/source/form/fmshimp.cxx:1552 #3 0x00007fffd8b9ff9e in FmFormShell::Execute (this=0x24637b8, rReq=...) at /home/master/src/libreoffice/libreoffice-3.4/svx/source/form/fmshell.cxx:727 #4 0x00007fffd8b9e28a in SfxStubFmFormShellExecute (pShell=0x24637b8, rReq=...) at /home/master/src/libreoffice/libreoffice-3.4/solver/340/unxlngx6/workdir/SdiTarget/svx/sdi/svxslots.hxx:290 Error is: - nId is set to 0 - pGrid->GetModelColumnPos(nId) returns GRID_COLUMN_NOT_FOUND, that is 65535 - next line uses it unconditionally without error checking (without checking whether it is GRID_COLUM_NOT_FOUND) That's easy enough to fix, but the root cause is probably higher up...
Problem is that the "Opposing Parties" grid (Table) controls get a handle column added twice, which gives two columns with the same ID of 0 (at positions 0 and 1), which confuses the code. Apparently position and/or id 0 is some kind of "special" value. I'm probably close to a solution.
Fixed in master (LibreOffice 3.5). Next step: backport to LO3.4
Created attachment 51393 [details] Fix for root cause See also http://lists.freedesktop.org/archives/libreoffice/2011-September/018340.html and other messages in the same thread.
Created attachment 51394 [details] Fix for crash, but not broken feature
(In reply to comment #19) > Created an attachment (id=51394) [details] > Fix for crash, but not broken feature Hi Lionel, Did your fix get pushed to master ? I have a build from 2 days ago, and my own home built I can try it on. Alex
(In reply to comment #20) > Did your fix get pushed to master ? Yes (see comment #17), but I was unable to get review to get it applied to libreoffice-3-4. See http://lists.freedesktop.org/archives/libreoffice/2011-September/018340.html
I have just pushed the fixes for LO-3.4.4, see http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4&id=45e6ceee47e4f1c5fdf800ae35b062f8387cf61c http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4&id=8590273b3ee8f34386bcb9e620fab10794b38a6f
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.