Bug Hunting Session
Bug 70703 - Base is crashing frequently when EDITING data and switching Forms
Summary: Base is crashing frequently when EDITING data and switching Forms
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.0.4.2 release
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: Caolán McNamara
URL:
Whiteboard: target:4.2.0 target:4.1.4
Keywords:
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2013-10-20 21:13 UTC by tim
Modified: 2015-07-08 08:14 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Crash log using jdbc (127.97 KB, text/plain)
2013-10-21 08:33 UTC, tim
Details
full debug backtrace (20.90 KB, text/plain)
2013-10-24 15:43 UTC, Lionel Elie Mamane
Details
Stand-alone crash demonstration (27.38 KB, application/vnd.oasis.opendocument.database)
2013-11-04 21:18 UTC, tim
Details
firebird-based reproduction case (67.98 KB, application/vnd.sun.xml.base)
2013-11-07 18:19 UTC, Lionel Elie Mamane
Details
valgrind --memcheck --track-origins=yes (17.65 KB, text/plain)
2013-11-07 18:22 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tim 2013-10-20 21:13:55 UTC
I have a Base application I have been using for some time.  I have not been creating or editing many records for some months.  I am now trying to create and editing several hundred entries, but LO 4.1.1.2 BASE is crashing frequently.

I am using the Ubuntu PPA release 4.1.  My BASE database is a front end to Mysql (now MariaDB), using a MySql(Native) connection.

The error reports in the syslog are of the type:

Oct 20 20:17:44 TimPassingham kernel: [25957.466878] soffice.bin[17498]: segfault at 40 ip 00007ff9cc4938b6 sp 00007fff4dd1b038 error 4 in libmergedlo.so[7ff9cadc0000+35ff000]

Oct 20 20:21:39 TimPassingham kernel: [26191.960815] soffice.bin[17908]: segfault at 40 ip 00007f27165808b6 sp 00007fff07eecdc8 error 4 in libmergedlo.so[7f2714ead000+35ff000]

Oct 20 20:33:33 TimPassingham kernel: [26905.744257] soffice.bin[18833]: segfault at 100 ip 00007fd74cf6cb5e sp 00007fff8c675170 error 4 in libdbalo.so[7fd74ce18000+2c5000]

Oct 20 20:58:32 TimPassingham kernel: [28405.243557] soffice.bin[20070]: segfault at 40 ip 00007fc31ba9c8b6 sp 00007fff36e56848 error 4 in libmergedlo.so[7fc31a3c9000+35ff000]

Oct 20 21:01:47 TimPassingham kernel: [28600.699904] soffice.bin[20697]: segfault at 7f83dc0b4598 ip 00007f83dc0b4598 sp 00007ffff3da3cf8 error 15

Oct 20 21:08:37 TimPassingham kernel: [29010.203425] soffice.bin[21002]: segfault at 61 ip 00007fd8a69748a8 sp 00007fffc5dea7a8 error 6 in libmergedlo.so[7fd8a52a1000+35ff000]

Oct 20 21:10:30 TimPassingham kernel: [29123.459668] soffice.bin[21103]: segfault at 7f0e67e5f230 ip 00007f0e7210c8a8 sp 00007fff8e1ac708 error 7 in libmergedlo.so[7f0e70a39000+35ff000]

They usually occur when I have entered or modified data in a form which has been invoked from a series of previous forms, close that one and automatically expect to see the previous one show again.  I use Basic macros to provide a type of modal user interface for the application.  To explain briefly, it is a music catalogue, where I have a record set (eg one or more CDs), with several performances, on tracks, of pieces and/or parts of pieces. I can therefore view the record set, edit/add a performance or an existing or new piece, and return back to the record set and see that it now has a new track on it.  There are quite a few bells and whistles.

A number of forms and sub-forms are involved, and a number of tables and queries.  My suspicion is that it is a GUI problem, as opposed to a Database problem, but I could well be wrong.  I have some .xsession-errors but they are not time-stamped so I can't match them up with the syslog and may well be unrelated.

I am well aware that this is insufficient information to help diagnose the problem(s).  Supplying a copy of a fully populated database and instructions on how to use a non-trivial application, with inconsistent results, is, however, not very practical.

Is there some way I can provide more detail of similar future crashes?  I'm no linux expert.
Comment 1 Alex Thurgood 2013-10-21 06:49:53 UTC
Hi Tim,

The native mysql connector has been announced recently as known to cause crashes when working with MariaDB databases, at least on Windows, due to a problem in one of the MariaDB libraries that were used in the builds of the connectors. This might also be the cause of your problem.

At present, people will either need to rebuild their native connectors (if they build themselves) or wait until updated connectors are made available.



Alex
Comment 2 Lionel Elie Mamane 2013-10-21 07:48:05 UTC
At first sight, this looks like bug 70496, but on the other hand, you are using the PPA, which (AFAIK) uses "--with-system-mysqlcppconn --with-system-mariadb" and links the MySQL/MariaDB connector against libmysqlclient (not the LGPL mariadb native client library). Right Bjoern? Then, this cannot be bug 70496.

Tim, please confirm that you are using the MySQL/MariaDB connector from the PPA, and not one downloaded elsewhere, such as e.g. on extensions.libreoffice.org or sourceforge. Make sure only the "system installed" one appears in your LibreOffice extensions manager.
Comment 3 tim 2013-10-21 08:03:49 UTC
In LO extensions it says I am using MySQL Connector 1.0.2 - no mention of 'system installed', although there is a padlock sign against it.  Synaptic states that it is version 1.0.2+LIBO4.1.1-0ubuntu1~precise1, so I guess that is correct.

I note that, using a Google search, libmergedlo.so has been reported as a cause of similar crashes elsewhere, possibly related to --enable-mergelibs.  I also see mention of issues relating this to menus.  I have noticed that the menu bars, top and bottom, have been disappearing on occasions.  I haven't yet correlated this with subsequent crashes, but it is possible.

I will try using JDBC.  After doing some more updates today with JDBC I will report back.
Comment 4 Lionel Elie Mamane 2013-10-21 08:21:14 UTC
(In reply to comment #3)
> In LO extensions it says I am using MySQL Connector 1.0.2 - no mention of
> 'system installed',

Below the list of extensions, you have three checkboxes:

 Type of Extension
                X Installation X Shared  X User

Uncheck "shared" and "user", leave "installation" checked. Does the MySQL connector still appear?

Uncheck "installation" and check "shared" and "user". Does the MySQL connector still appear?

If the answers are "yes" and "no" (in that order), then you are using a MySQL connector from packages.
Comment 5 tim 2013-10-21 08:33:14 UTC
Created attachment 87911 [details]
Crash log using jdbc

The connector remains when shared and 'user' are unticked.

Using JDBC I have just had repeated crashes, and repeated tool bar (I said menu - I should have said tool) disappearances.

Anything else I should try?  Any way I can report more diagnostic data?

Using JDBC I am now getting JRE errors, sample attached.
Comment 6 tim 2013-10-21 08:41:22 UTC
To clarify:

I had a look at the syslog (and kern.log).  With JDBC I am not getting the segfaults, but I am getting the JRE crashes and toolbar disappearances.  

From a user perspective it looks like the same problem.
Comment 7 tim 2013-10-21 08:41:36 UTC
To clarify:

I had a look at the syslog (and kern.log).  With JDBC I am not getting the segfaults, but I am getting the JRE crashes and toolbar disappearances.  

From a user perspective it looks like the same problem.
Comment 8 Lionel Elie Mamane 2013-10-21 09:20:57 UTC
Yes, when Java is loaded it "takes control" of segfaults and replaces them with these documented aborts. This is most probably the same problem, and probably not database-related.

I say that because of:

Stack: [0x00007fff56b10000,0x00007fff56c10000],  sp=0x00007fff56c0dd28,  free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libmergedlo.so+0x16d38a8]  SfxShell::Invalidate(unsigned short)+0x68


Probably a general problem with LibreOffice. Tim, do you use (heavily) any other part of LibreOffice than the database? E.g. writer, calc or impress? If yes, do you get the same kind of crash/aborts also?
Comment 9 tim 2013-10-21 09:37:24 UTC
I use Writer for documents, and have a few quite complex CALC sheets (one with several dozen sheets in it).  I've had no problems with either.

With the BASE crashes and toolbar disappearances it always seems to be when I have opened one form, hide that one and open another, close the latter and make the first one visible again.  I have not yet quite managed to make it happen consistently and reproducibly.  I will try and see if I can create a repeatable demo when I get time.

Is there any more crash data or other info I can supply?
Comment 10 Lionel Elie Mamane 2013-10-21 09:40:55 UTC
@bjoern: is there some Ubuntu documentation on how to easily / cleanly get backtraces from the LibreOffice PPA?
Comment 11 tim 2013-10-21 13:15:04 UTC
Some progress.  I have found that making a form invisible and then visible again hides the toolbars.  I will raise a separate bug report on Base for this, although it may well be more widespread.  I will provide a self-contained test form.

Having stopped making forms invisible (for now at least) the Mysql(Native) version did crash, but the JDBC connection is holding up thus far.  I'll stay with the JDBC for now and report here if it crashes again.  I suppose it is not inconceivable that the problem with toolbars was what was making the JDBC version fail with a JRE fault, but I don't have enough knowledge to interpret the JRE log I attached earlier.
Comment 12 tim 2013-10-21 13:37:14 UTC
I have raised #70724 for the form toolbar disappearance issue.
Comment 13 tim 2013-10-21 16:38:38 UTC
Even with none of my forms being hidden/visible on the fly I am still getting the same volume of crashes using JDBC.

It almost always seems to happen when I close a form, saving the data, and returning to a form that has a summary of that data on it.

This type of activity has never been 100% stable, with occasional crashes, but is now failing 20-30% of the time.  

I'm unclear how to proceed.  If the previous JRE crash dump doesn't help, I need to find a way of providing more information.
Comment 14 tim 2013-10-22 12:31:46 UTC
I now have a consistently repeatable set for actions which crashes BASE, on a 64 bit ubuntu 12.04 desktop and 32 bit xubuntu 12.04 laptop.

I have 13MB of an 'airport' crash file from soffice.bin if that's any help, from running it on the laptop.  This seems to have a stack trace, core dump, etc.

If it is of use, can I PM it to someone such as Lionel?  I don't quite know what such a file could reveal on a public site such as this.
Comment 15 Lionel Elie Mamane 2013-10-22 12:50:21 UTC
(In reply to comment #14)
> I now have a consistently repeatable set for actions which crashes BASE, on
> a 64 bit ubuntu 12.04 desktop and 32 bit xubuntu 12.04 laptop.

Please post this "consistently repeatable set of actions" here, along with the underlying database. Or if the database cannot be made public, then send me privately by email a download URL.

> I have 13MB of an 'airport' crash file from soffice.bin if that's any help,
> from running it on the laptop.  This seems to have a stack trace, core dump,
> etc.

I'm not familiar with 'airport crash' file, and a search does not give any useful link. But I'm very interested in a full stack trace!

> If it is of use, can I PM it to someone such as Lionel?  I don't quite know
> what such a file could reveal on a public site such as this.

In doubt, email me a download link and I'll take a look.
Comment 16 tim 2013-10-22 14:32:04 UTC
I've emailed the dump to Lionel. I understand it would be better if I was running the debug version of LO.  I'll look into that.

I've also posted the database & odb to him, with instructions.  

I hope this all helps.
Comment 17 tim 2013-10-23 19:11:53 UTC
I managed to get some more time on a Windows 7 64 bit PC, LO 4.2.1.3, running the same odb, connecting over my home network.

Base crashes in the same way. 

I have sent the ubuntu stack trace, having installed the .dbf files for LO, to Lionel.
Comment 18 Lionel Elie Mamane 2013-10-23 20:24:03 UTC
Reproduced. The stack trace has basically no database component, it is all vcl / sfx2 / etc. So outside of my area of expertise... I'll try to get enough info for someone else to pick this up.

Reproduced also on master.

I'll post more information ASAP.
Comment 19 Lionel Elie Mamane 2013-10-24 15:29:33 UTC
The event that triggers the crash is most definitely focus switch from one form to the other, whether by macro or by mouse pointer. It is systematically reproduceable with the system that Tim sent me, but I haven't been able to make a simplified reproduction case.

I attach the backtrace in the hope that someone will have a brainwave...
Comment 20 Lionel Elie Mamane 2013-10-24 15:43:06 UTC
Created attachment 88083 [details]
full debug backtrace
Comment 21 tim 2013-10-24 15:51:53 UTC
I'm somewhat relieved it's reproducible by others.  I've now seen it on 2 ubuntu systems and a Windows system.  It's a fairly new problem - I don't have older versions of LO I can retest on. 

I have several screens and dialogues where I flip focus from one to another.  Some crash every time, some crash sometimes (or at least I haven't detected the common exact sequence of actions), and some work all the time.  I've not fathomed a pattern, so haven't managed to produce a simplified version.
Comment 22 tim 2013-10-27 16:04:50 UTC
I have reproduced this using 4.0.4.2 and now 4.1.2.3, on ubuntu 12.04.

I tried to get back to a version 3.5 or 3.6 but failed to get it to install as a standard ubuntu package.  So I am now on 4.1.2.3 since that has been released to ubuntu.

I wondered if there was a fault in the odb itself, sine I now seem unable to create a new form using the wizard in this database, but I can in a different one. This is very strange.

So I recreated the odb by copying each macro, dialogue, form and query to a new odb.  I still get the same problem.  I also created a new form not using the wizard, which works OK.
Comment 23 tim 2013-11-01 13:09:34 UTC
I was trying to find a fault elsewhere, and thought I would try Xray for looking at objects, having previously used Mri.

In almost every case I have tried I get much the same crash as for this report on excuting the Xray line.

It looks to me as if the this is a bug in the handling of drawing or re-drawing forms. 

Because of this problem I am busy trying to re-engineer how I perform certain actions in my application so as avoid this problem.  Not knowing what causes the problem is in any detail means this I have to do this by pot luck.  This is very time consuming and frustrating, to say the least.
Comment 24 tim 2013-11-01 15:25:07 UTC
In release 4.1.2 I have been getting the following on recovery from some crashes:

BASIC runtime error.
An exception occurred 
Type: com.sun.star.uno.RuntimeException
Message: invalid attempt to assign an empty interface of type com.sun.star.frame.XFrame!.
Comment 25 tim 2013-11-04 13:31:35 UTC
I'm still hoping that someone will look at this at some point.  I have spent countless hours trying to circumvent it and to replicate in a simpler form.

I have done some experiments which may shed some light on possible causes.

I have a form (A) with a subform (S).  In subform (S) I go to a 'new record', and then use a button to select another form (B) which will determine part of the essential content of subform (S).  This invokes a dialogue, which I use to open the form (B).  All is fine so far.

On form (B) I 'select' the item I want.  This invokes a macro to store the key to the selected record in subform (S) and then close form (B).  At the point at which this value is stored in subform (S) the 'beforeupdate' event is triggered in subform (S) (and it seems this usually happens before the calling macro ends).  The calling form (A) and subform (S) may be made visible before or after this value is stored (I have tried both with no change to the result).

This beforeupdate event does a number of calculations and database lookups to complete the data required for the record in subform (S).  It is invoked twice - once for the database form and once for the document (as is true for all beforeupdate events - strange are the ways of LibreOffice Base events).  The second call does almost nothing.  There is also an AfterUpdate event macro which does almost nothing (it used to but I suppressed it in order to find the cause of the crash).

If I let all this run it crashes every time.  

If I place a breakpoint in the beforeupdate event (with the Basic IDE) at a point that is invoked only once, and wait briefly before resuming execution, it does not crash.  I tried inserting a 'wait 2000' instead of a breakpoint, but that did not work.

Other examples of the crash are less repeatable, which made me think it is related to some sort of timing issue between screen handling and macros running in the background.  I have found that when there is a lot of macro processing going on at the time a form is being updated and receiving the focus on screen, crashes are more likely.

I have simplified my explanation of the number of macro actions occurring somewhat, but the above gives the essence.
Comment 26 tim 2013-11-04 21:18:27 UTC
Created attachment 88654 [details]
Stand-alone crash demonstration

I have now managed to replicate at least one case where BASE crashes.  The attached self-contained odb demonstrates this.

Open the ODB.

Open Form 'Table1'.  This shows records from Table 1 (Id1..) with a subform containing records from Table2 (Id2..)

Place the cursor on field Id2 in the subform.

Hit the 'new record' forward arrow (below) to create a new subform record.

Hit the 'Set' Button

An error message is displayed that Data2 is blank (it is mandatory).  Press OK and it crashes.

The only code is run when the 'Set' button is pressed.  This opens Form 'Form1',
Brings it to the front, sets a value in field Id3 in the subform record (which is a link to table Table3) brings the Table1 Form to the front and closes form Form1.  

It may be that an even simpler demo is possible, but I am hoping this is simple enough for someone to trace the fault.

I'd be most grateful if someone could tell me whether they can replicate the fault using this demo.
Comment 27 Lionel Elie Mamane 2013-11-07 13:09:07 UTC
(In reply to comment #26)
> Created attachment 88654 [details]
> Stand-alone crash demonstration

> I have now managed to replicate at least one case where BASE crashes.  The
> attached self-contained odb demonstrates this.

Yup, reproduced with that self-contained example. Thank you very much!

The backtrace is the same as attachment 88083 [details] (with a layer of Java
signal handler added since this is embedded HSQLDB).
Comment 28 tim 2013-11-07 13:15:07 UTC
Thanks for letting me know.
Comment 29 Michael Meeks 2013-11-07 15:52:33 UTC
It'd be ideal to get a valgrind trace of a build with debug symbols, and without java - ie. re-building the test with firebird not HSQLDB (?), any chance of that.
Comment 30 tim 2013-11-07 16:44:51 UTC
I don't think I can help at present.  I don't know how to create an odb using firebird.  However, if someone gave me enough pointers I might be able to get something put together.
Comment 31 tim 2013-11-07 17:55:46 UTC
I got as far as changing content.xml as per the instructions at http://www.ahunt.org/2013/07/firebird-now-in-master/ , but when I try to create a table it says "The connection to the data source "Firebird" could not be established.... No SDBC driver was found for the given URL."

I don't know if I should have separately installed firebird, or what else I have missed.  Maybe the version from the ubuntu ppa doesn't include the driver?
Comment 32 Lionel Elie Mamane 2013-11-07 18:01:18 UTC
(In reply to comment #31)
> I got as far as changing content.xml as per the instructions at
> http://www.ahunt.org/2013/07/firebird-now-in-master/ , (...)

firebird is a new (experimental) feature of LibreOffice 4.2.

I'll do the "create a firebird-based example and make a valgrind log". Thanks for your eagerness.
Comment 33 Lionel Elie Mamane 2013-11-07 18:19:46 UTC
Created attachment 88840 [details]
firebird-based reproduction case

Needs (from master / 4.2.0.alpha branch):

commit c2ad6017e66909e9797bc728ac28a9575c84343e
Author: Lionel Elie Mamane <lionel@mamane.lu>
Date:   Thu Nov 7 19:12:23 2013 +0100

or later.

Exactly same reproduction instructions as comment 26
(the error message is a bit different, but same effect).
Comment 34 Lionel Elie Mamane 2013-11-07 18:22:51 UTC
Created attachment 88841 [details]
valgrind --memcheck --track-origins=yes

This gives us confirmation that indeed a free()d pointer is dereferenced. The stack trace that free()d it is again all svx/vcl/...
Comment 35 tim 2013-11-09 13:09:04 UTC
I have tried to reproduce this problem using a simple form, without including a subform, and failed to do so.

I have a hypothesis as to a possible cause.

I suspect that the problem occurs when a main (top level) form receives the focus when a subform has been changed but not saved.  

Normally, when one updates data in a subform manually and click on the owning form, this causes the subform to be saved before the focus is completely moved to the owning form.  

When one updates data in a subform in a macro when another form has the focus, and then move the focus back (in the example using the 'tofront' method on the form window), the owning form may find it has the focus possibly before the subform has been properly been saved.  This may even also cause the main form to attempt to refresh the data in the subform.

Just a thought .....
Comment 36 Michael Meeks 2013-11-12 17:09:39 UTC
warn:sfx.control:21234:1:sfx2/source/control/dispatch.cxx:1469: Childwindow slot missing: 10365

==21234== Invalid read of size 8
==21234==    at 0x7A1F2CF: SfxShell::DoActivate_Impl(SfxViewFrame*, unsigned char) (shell.cxx:554)
==21234==    by 0x7D7FDA1: SfxDispatcher::FlushImpl() (dispatch.cxx:1638)
==21234==    by 0x36011951: SfxDispatcher::Flush() (dispatch.hxx:237)
==21234==    by 0x3600A1B8: SwView::SelectShell() (view.cxx:436)
==21234==    by 0x3600A7C7: SwView::AttrChangedNotify(void*) (view.cxx:505)
...
==21234==  Address 0x2d671420 is 0 bytes inside a block of size 176 free'd
==21234==    at 0x4C299DC: operator delete(void*) (vg_replace_malloc.c:457)
==21234==    by 0x35FB9499: SwNavigationShell::~SwNavigationShell() (navsh.hxx:16)
==21234==    by 0x7D7FEAE: SfxDispatcher::FlushImpl() (dispatch.cxx:1647)
==21234==    by 0x36011951: SfxDispatcher::Flush() (dispatch.hxx:237)
==21234==    by 0x3600A1B8: SwView::SelectShell() (view.cxx:436)
==21234==    by 0x3600A7C7: SwView::AttrChangedNotify(void*) (view.cxx:505)

Looks a bit painful; clearly the 'delete' in FlushUmpl() occurs after the DoActivate_Impl() call but yet a pointer to that deleted thing is left malingering around unpleasantly =)

Of course a nearly ideal fix would be to convert all SfxShell sub-classes to be reference counted with rtl::Reference<> or a boost intrusive ptr or somesuch. There are 500 hits of SfxShell and ~30 sub-classes, so that's quite a big cleanup job. We would swap 'Delete' for a new 'Dispose' method in that case I guess.
Comment 37 Caolán McNamara 2013-11-20 14:53:37 UTC
If we look at the full stack the deletion happens in a SfxDispatcher::FlushImpl call which is deeply embedded inside another SfxDispatcher::FlushImpl call (on the same object). The inner SfxDispatcher::FlushImpl deletes some stuff, and the outer SfxDispatcher::FlushImpl doesn' know its gone
Comment 38 Commit Notification 2013-11-20 16:32:04 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=32a621027f1a234a85b3659b93752a9263d8e860

Resolves: fdo#70703 guard against FlushImpl inside FlushImpl



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 39 Caolán McNamara 2013-11-20 16:37:03 UTC
A bit of a Rube Goldberg device, but it seems to work
Comment 40 tim 2013-11-20 22:34:07 UTC
I can't easily test this until a version comes from the ubuntu ppa.  I don't know when this will be, even on the pre-release ppa.

The reason I have to do this is because the mysql(native) connection only works if I use the ppa to get both LO and the connector.  If I don't use this method, and just download from your download site, the connector does not work.

Will this get into 4.1.4, or 4.2?  I'll try it as soon as I can.
Comment 41 tim 2013-11-27 11:37:00 UTC
I have briefly tested this using LO 4.2.0.0 beta1 installed in parallel on my ubuntu 64 bit system.

I have tested both with the stand-alone demo I produced, and with my full (MariaDB) database system {using Mysql(JDBC) since I can't get Mysql(Native) to work on my platform until LO 4.2 is released for ubuntu}.

I verify that the fix has worked, and have changed the status accordingly.  I had scenarios that always caused LO to crash, and now they don't.

Thanks very much.  I'll continue to use this beta from now on (unless it gives me any other problems).

Whilst researching this issue I did find a few emails and other bug reports that looked as if they might be related, eg http://listarchives.libreoffice.org/global/users/msg33976.html.  I don't know if they are, but if so it may be worth putting something in the 4.2 release notes regarding similar types of problem.
Comment 42 Commit Notification 2013-12-04 13:31:08 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5d98639ec39f302df3dd38498703630e0556938d&h=libreoffice-4-1

Resolves: fdo#70703 guard against FlushImpl inside FlushImpl


It will be available in LibreOffice 4.1.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 43 Commit Notification 2013-12-04 15:17:03 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-1-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=039fb1d5671274ba868dbbf12c8d606da27fb469&h=libreoffice-4-1-4

Resolves: fdo#70703 guard against FlushImpl inside FlushImpl


It will be available already in LibreOffice 4.1.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 44 tim 2015-07-07 20:39:01 UTC
Running "Version: 4.4.4.3 Build ID: 40m0(Build:3) Locale: en_GB.UTF-8" this problem, or something very like it, has come back again.  Base crashes in the same circumstances as before, about 20-30% of the time.

However, the 'Stand alone demo' that I managed to produce last time around does not appear to crash, so this may be caused by a slightly different problem.

What is the best way of proceeding?  Please bear in mind that my skills and knowledge are somewhat limited, but I'll do what I can to help track this down.

I haven't changed the status of this report.
Comment 45 Lionel Elie Mamane 2015-07-08 07:14:34 UTC
(In reply to tim from comment #44)
> What is the best way of proceeding?

The best would be to open a new bug report, putting in CC the people involved here (CC list, "assigned to", ...) with a concrete example of "open this file, do exactly this and that and then it crashes". Next best thing is "do exactly this and that several times and then after a few times it usually crashes".
Comment 46 tim 2015-07-08 07:25:37 UTC
I'll open a new report, but giving examples of database crashes is fraught with difficulty.  It's a relatively complicated application, with a lot of code, and a fair bit of data, that I can't very well upload, so I can't (as yet) say 'do this', 'do that'.  

There is no trace of the crashes.  I'll try running the debug version first, before raising a new report, to try and get some evidence that something has failed.
Comment 47 tim 2015-07-08 08:14:54 UTC
I've raised #92617.