Bug Hunting Session
Bug 40701 - Base crashes with runtime error when "Find Record" button is clicked with certain documents
Summary: Base crashes with runtime error when "Find Record" button is clicked with cer...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.4.3 release
Hardware: x86 (IA32) All
: high blocker
Assignee: Lionel Elie Mamane
URL:
Whiteboard:
Keywords: patch, regression
Depends on:
Blocks:
 
Reported: 2011-09-07 19:09 UTC by Steven Shelton
Modified: 2011-12-23 13:26 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Database that crashes when "Find Record" is clicked (159.82 KB, application/vnd.sun.xml.base)
2011-09-08 09:37 UTC, Steven Shelton
Details
mac osx crash trace - search function in ODB (61.18 KB, text/plain)
2011-09-08 10:10 UTC, Alex Thurgood
Details
Fix for root cause (1.13 KB, patch)
2011-09-20 02:33 UTC, Lionel Elie Mamane
Details
Fix for crash, but not broken feature (1017 bytes, patch)
2011-09-20 02:34 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steven Shelton 2011-09-07 19:09:41 UTC
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.
Comment 1 vitriol 2011-09-07 22:09:37 UTC
I'm non able to reproduce this crash. Cloud you please attach a sample document?
Comment 2 Alex Thurgood 2011-09-08 01:19:31 UTC
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
Comment 3 vitriol 2011-09-08 01:26:17 UTC
I use windows, and it works for me. A sample document will be useful.
Comment 4 Alex Thurgood 2011-09-08 05:45:06 UTC
(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
Comment 5 Steven Shelton 2011-09-08 09:37:58 UTC
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.
Comment 6 vitriol 2011-09-08 09:51:18 UTC
I confirm the crash with LibO 3.4.3 under Win7. No crash with LibO 3.3.x -> Regression
Comment 7 Alex Thurgood 2011-09-08 10:01:23 UTC
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
Comment 8 Alex Thurgood 2011-09-08 10:01:54 UTC
changed platform to all.

Alex
Comment 9 Alex Thurgood 2011-09-08 10:03:11 UTC
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
Comment 10 Alex Thurgood 2011-09-08 10:06:51 UTC
(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
Comment 11 Alex Thurgood 2011-09-08 10:10:04 UTC
Created attachment 50987 [details]
mac osx crash trace - search function in ODB
Comment 12 Alex Thurgood 2011-09-08 10:24:49 UTC
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
Comment 13 Steven Shelton 2011-09-08 11:24:56 UTC
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!)
Comment 14 Alex Thurgood 2011-09-08 11:45:02 UTC
(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 :-))
Comment 15 Lionel Elie Mamane 2011-09-09 14:06:40 UTC
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...
Comment 16 Lionel Elie Mamane 2011-09-11 12:53:05 UTC
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.
Comment 17 Lionel Elie Mamane 2011-09-11 14:08:33 UTC
Fixed in master (LibreOffice 3.5).
Next step: backport to LO3.4
Comment 18 Lionel Elie Mamane 2011-09-20 02:33:23 UTC
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.
Comment 19 Lionel Elie Mamane 2011-09-20 02:34:02 UTC
Created attachment 51394 [details]
Fix for crash, but not broken feature
Comment 20 Alex Thurgood 2011-09-26 09:46:51 UTC
(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
Comment 21 Lionel Elie Mamane 2011-10-09 03:41:56 UTC
(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
Comment 23 Björn Michaelsen 2011-12-23 13:26:28 UTC
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.