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

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.

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.

(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.

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.

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.

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.

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?

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?

@bjoern: is there some Ubuntu documentation on how to easily / cleanly get backtraces from the LibreOffice PPA?

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.

I have raised #70724 for the form toolbar disappearance issue.

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.

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.

(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.

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.

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.

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.

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...

Created attachment 88083 [details]
full debug backtrace

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.

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.

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.

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!.

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.

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.

(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).

Thanks for letting me know.

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.

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.

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?

(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.

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).

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/...

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 .....

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.

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

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.

A bit of a Rube Goldberg device, but it seems to work

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.

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.

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.

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.

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.

(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".

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.

I've raised #92617.