Bug 92617 - Base is crashing frequently when EDITING data and switching Forms
Summary: Base is crashing frequently when EDITING data and switching Forms
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.6.7.2 release
Hardware: x86-64 (AMD64) All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0
Keywords: haveBacktrace
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2015-07-08 08:06 UTC by tim
Modified: 2018-05-24 11:33 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
An extract of the ubuntu crash report (29.82 KB, application/zip)
2015-07-08 08:06 UTC, tim
Details
hs_err_pid file (19.96 KB, application/zip)
2015-07-08 08:13 UTC, tim
Details
Test case database (22.73 KB, application/vnd.oasis.opendocument.database)
2015-07-11 15:15 UTC, tim
Details
backtrace (31.44 KB, text/plain)
2015-07-12 12:28 UTC, Alex Thurgood
Details
console logs + bt with debug symbols (10.37 KB, text/plain)
2015-08-15 08:15 UTC, Julien Nabet
Details
valgrind log (47.90 KB, application/x-tar-gz)
2015-08-15 09:15 UTC, Julien Nabet
Details
backtrace mentioned in comment 30 (28.67 KB, text/plain)
2016-03-17 17:05 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tim 2015-07-08 08:06:50 UTC
Created attachment 117119 [details]
An extract of the ubuntu crash report

In bug #70703 I had regular crashes switching forms.  That was fixed.  However, the same symptom has now resurfaced, but it appears to be a slightly different cause since my demo of that crash does not crash in 4.4.4.3.

I'm running MariaDB (10.0.20) and Libreoffice from the Ubuntu 14.04 ppas.

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

I have run this in the debug version, and have a ubuntu crash report.  That's over 40MB, so not very practical to upload here.  I have therefore edited it to remove the core dump and attached that.
Comment 1 tim 2015-07-08 08:10:04 UTC
I have taken the liberty of copying the email addresses from #70703 to this report.
Comment 2 tim 2015-07-08 08:13:50 UTC
Created attachment 117120 [details]
hs_err_pid file

I just found a related java error log, attached.
Comment 3 Lionel Elie Mamane 2015-07-08 08:51:12 UTC
The Ubuntu crash report contains a backtrace. It points to this method in file svx/source/form/formcontrolling.cxx:

    bool FormControllerHelper::isModifiedRow() const
    {
        bool bIs = false;
        if ( m_xFormOperations.is() )
            bIs = m_xFormOperations->isModifiedRow();
        return bIs;
    }

and seems to be the line "m_xFormOperations.is()", where "&m_xFormOperations" is 0x40, an obviously invalid value. I deduce that from one frame down:

 #7  is (this=0x40) at /build/libreoffice-A1OEbm/libreoffice-4.4.4~rc3/include/com/sun/star/uno/Reference.h:93
Comment 4 tim 2015-07-09 18:57:23 UTC
I am trying to pin down when and why the crash occurs.

I am in one form's (A) subform (B).  From there I open another form (C) that contains a subform (D).  

If the focus is on subform (D) when form (C) is closed then tracing my macros I get to form D's afterupdate macro which seems to execute OK (all the values look to be correct) but on ending that macro Base crashes.

If I manually move the focus from (D) to (C) before closing (C) then no crash occurs.

I am trying to reproduce this in a simple fashion, but haven't succeeded yet.

I mention this now because what I think Lionel is saying is that a pointer is empty, and I wonder if form (C) has disappeared before subform (D) has completed its actions.
Comment 5 tim 2015-07-11 15:15:02 UTC
Created attachment 117180 [details]
Test case database

This was not easy to reproduce, but I have just managed to do so in the attached self-contained database. 

I don't know if all the complexities and features included in the demo are require to generate the crash.  

There are 4 tables.  Table1, with Table2 containing records that depend on Table1 records and also depend on Table3 records.  Table4 has records that depend on Table3 records.  

There are 2 forms.  Table1 has Table1 records with a subform for Table2 records linked to Table1.  

Table3 has Table3 records with a subform for Table4 records linked to Table3.

To make it crash follow these steps:

1. Open Table1 form
2. Enter text in text1
3. Enter text in text2 (which is in the Table2 subform)
4. Press button 'Open Table3'
5. Enter text in text 3
6. Enter text in text 4 (which is in the Table 4 subform)
7. Press the Exit button (do nothing else - if you put the cursor in a Table3 field first it may not crash)
8. LO Base will ask you 'Do you want to save your changes'
9. Press Yes
10. It should crash.

There are 4 (very ugly) macros created for testing this.  Table4BeforeUpdate is the 'before update' routine for the Table4 subform.  OpenForm is the routine for opening the Table3 form from Table2.  ExitTable3 is called when the Exit button is pressed on Table3.  CloseTable3 is called as the 'Document is going to be closed' routine on Table 3.

The crash seems to be due to some sort of timing problem.  When debugging in Table4BeforeUpdate there is a nested call to the 'before update' routine for the Table 4 subform.  I had to add a delay to that routine to make it crash.  In my real system I just do a lot more work in the equivalent forms that creates a long enough delay for the crash to occur more often than not.
Comment 6 Alex Thurgood 2015-07-12 12:13:35 UTC
Version: 5.1.0.0.alpha1+
Build ID: 9136f2344af88d524b6c10b6b2dfd6017bba60ec
Locale: fr-FR (fr.UTF-8)

OSX 10.10.4

Confirming crash with Tim's file and steps in comment 5
Comment 7 Alex Thurgood 2015-07-12 12:22:45 UTC
On master, running in lldb, it first stops on its own when opening form Table1

Process 12524 stopped
* thread #18: tid = 0x1dd248, 0x000000012bcf329b, stop reason = signal SIGBUS
    frame #0: 0x000000012bcf329b
->  0x12bcf329b: testl  -0x1ad3b1a1(%rip), %eax
    0x12bcf32a1: retq   
    0x12bcf32a2: nop    
    0x12bcf32a3: nop    

Continuing to clicking on Exit button :

warn:sal.osl.mutex:12524:1:sal/osl/unx/mutex.cxx:82: pthread_mutex_destroy failed: Resource busy
warn:legacy.osl:12524:1:svx/source/form/formcontroller.cxx:3573: caught an exception!
in function:bool svxform::FormController::checkFormComponentValidity(rtl::OUString &, Reference<com::sun::star::awt::XControlModel> &)
type: com.sun.star.lang.DisposedException
context: N7svxform14FormControllerE

warn:legacy.osl:12524:1:svx/source/form/formcontroller.cxx:3659: caught an exception!
in function:bool svxform::(anonymous namespace)::lcl_shouldValidateRequiredFields_nothrow(const Reference<com::sun::star::uno::XInterface> &)
type: com.sun.star.uno.RuntimeException
message: unsatisfied query for interface of type com.sun.star.container.XChild!

warn:legacy.osl:12524:1:svx/source/form/formcontroller.cxx:3705: FormController::approveRowChange: no column infos!
error: libdbalo.dylib debug map object file '/Volumes/BUILDHD/Shared/LO/core/workdir/CxxObject/dbaccess/source/core/api/RowSetCache.o' has changed (actual time is 0x559ad0a7, debug map time is 0x5596928a) since this executable was linked, file will be ignored
Process 12524 stopped
* thread #1: tid = 0x1dd143, 0x000000011ce5fb4e libdbalo.dylib`dbaccess::ORowSetCache::insertRow(std::__1::vector<com::sun::star::uno::Any, std::__1::allocator<com::sun::star::uno::Any> >&) + 46, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV
    frame #0: 0x000000011ce5fb4e libdbalo.dylib`dbaccess::ORowSetCache::insertRow(std::__1::vector<com::sun::star::uno::Any, std::__1::allocator<com::sun::star::uno::Any> >&) + 46
libdbalo.dylib`dbaccess::ORowSetCache::insertRow:
->  0x11ce5fb4e <+46>: movq   0xd0(%rax), %rsi
    0x11ce5fb55 <+53>: testb  $0x1, (%rsi)
    0x11ce5fb58 <+56>: movq   %rax, -0x2d8(%rbp)
    0x11ce5fb5f <+63>: je     0x11ce5fb93               ; <+115>
Comment 8 Alex Thurgood 2015-07-12 12:28:09 UTC
Created attachment 117189 [details]
backtrace
Comment 9 tim 2015-07-12 12:42:25 UTC
It may be useful to note that if you remove the 'wait' from the Table4BeforeUpdate macro it does not crash.  

That's why I think it's some form of timing issue, with something being closed/deleted/dereferenced before it should be if things take too long.
Comment 10 tim 2015-07-21 11:36:20 UTC
(In reply to tim from comment #9)
> It may be useful to note that if you remove the 'wait' from the
> Table4BeforeUpdate macro it does not crash.  
> 
> That's why I think it's some form of timing issue, with something being
> closed/deleted/dereferenced before it should be if things take too long.
I should stress that this is the case for the demo database I posted.  

In the real world case Base crashes much of the time due to this problem, but not every time.  There are, of course, no 'wait' statements that I can remove.
Comment 11 tim 2015-08-12 19:38:24 UTC
My LibreOffice has just updated to Version: 5.0.0.5, Build ID: 00m0(Build:5), Locale: en-GB (en_GB.UTF-8).

This bug is still present.
Comment 12 Julien Nabet 2015-08-15 08:15:16 UTC
Created attachment 117926 [details]
console logs + bt with debug symbols

On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.
Comment 13 Julien Nabet 2015-08-15 08:25:40 UTC
If I don't misunderstand the bt, the pb is m_pCache is null. But how can it be since some lines above in dbaccess/source/core/api/RowSet.cxx, we've got this:
    886     if(!m_pCache || !m_bNew || !m_bModified || m_nResultSetConcurrency == ResultSetConcurrency::READ_ONLY)
    887         throwFunctionSequenceException(*this);
Moreover, there's ::osl::ResettableMutexGuard aGuard( *m_pMutex );
See http://opengrok.libreoffice.org/xref/core/dbaccess/source/core/api/RowSet.cxx#884
So even with multithread case, it should be ok
Comment 14 Lionel Elie Mamane 2015-08-15 08:56:30 UTC
(In reply to Julien Nabet from comment #13)
> If I don't misunderstand the bt, the pb is m_pCache is null. But how can it
> be since some lines above in dbaccess/source/core/api/RowSet.cxx, we've got
> this:
>     886     if(!m_pCache || !m_bNew || !m_bModified ||
> m_nResultSetConcurrency == ResultSetConcurrency::READ_ONLY)
>     887         throwFunctionSequenceException(*this);
> Moreover, there's ::osl::ResettableMutexGuard aGuard( *m_pMutex );
> See
> http://opengrok.libreoffice.org/xref/core/dbaccess/source/core/api/RowSet.
> cxx#884
> So even with multithread case, it should be ok

aGuard is a resettable guard, and that's exactly what:
  notifyAllListenersRowBeforeChange(aGuard,aEvt);
does:

void ORowSet::notifyAllListenersRowBeforeChange(::osl::ResettableMutexGuard& _rGuard,const RowChangeEvent &aEvt)
{
    NOTIFY_LISTERNERS_CHECK(m_aApproveListeners,XRowSetApproveListener,approveRowChange);
(...)

and:

#define NOTIFY_LISTERNERS_CHECK(_rListeners,T,method)                             \
     (...)                                                                                   \
     _rGuard.clear();
Comment 15 Julien Nabet 2015-08-15 09:15:32 UTC
Created attachment 117928 [details]
valgrind log

In addition of Valgrind trace, I added some traces at DELETEZ(m_pCache) and at m_pCache = new...
Comment 16 Julien Nabet 2015-08-15 10:17:05 UTC
Caolan: I don't know if it's related to the crash but I noticed this in Valgrind trace
  29935 ==29672== Conditional jump or move depends on uninitialised value(s)
  29936 ==29672==    at 0xAD31CFB: Rectangle::IsInside(Point const&) const (gen.cxx:139)
  29937 ==29672==    by 0xBBE301E: vcl::Window::ImplHitTest(Point const&) (mouse.cxx:62)
  29938 ==29672==    by 0xBAED29A: vcl::Window::ImplFindWindow(Point const&) (stacking.cxx:679)
  29939 ==29672==    by 0xBC9F259: HandleGestureEventBase::FindTarget() (winproc.cxx:1423)
  29940 ==29672==    by 0xBC9F7BF: HandleGestureEvent::HandleEvent() (winproc.cxx:1562)
  29941 ==29672==    by 0xBC9F8BF: ImplHandleSwipe(vcl::Window*, SalSwipeEvent const&) (winproc.cxx:1593)
  29942 ==29672==    by 0xBCA2D26: ImplWindowFrameProc(vcl::Window*, SalFrame*, unsigned short, void const*) (winproc.cxx:2670)
  29943 ==29672==    by 0x1B5F5000: SalFrame::CallCallback(unsigned short, void const*) const (in /home/julien/compile-libreoffice/libreoffice/instdir/program/libvclplug_gtk3lo.so)
  29944 ==29672==    by 0x1B5F0F64: GtkSalFrame::gestureSwipe(_GtkGestureSwipe*, double, double, void*) (gtksalframe.cxx:3581)

(I use gtk3)
false positive from Valgrind or real bug?
Comment 17 Julien Nabet 2015-08-15 10:23:12 UTC
Additional traces before segfault:
warn:sw.core:30105:1:sw/source/core/attr/calbck.cxx:170: a 21SwAccessibleParagraph client added as listener to a 16SwTextFormatColl during client iteration.
TODO DELETEZ m_pCache
TODO freeResources from ORowSet::close
TODO DELETEZ m_pCache
TODO freeResources from ORowSet::close
TODO DELETEZ m_pCache
TODO freeResources from ORowSet::disposing
TODO DELETEZ m_pCache
TODO freeResources from ORowSet::disposing
warn:legacy.osl:30105:1:sw/source/core/attr/format.cxx:228: SwFormat::~SwFormat: Def dependents!
Comment 18 tim 2015-11-13 08:53:25 UTC
Is there any more on this?  I still get these crashes at times.
Comment 19 tim 2015-12-04 12:59:56 UTC
I'm going quietly nuts on this.  I've a load of stuff to add using my application, and it's now crashing almost every time.
Comment 20 Julien Nabet 2015-12-31 10:57:14 UTC
I upgrade importance of this one since:
- it's a crash
- it's a regression

Just for the update, I still reproduce with master sources updated yesterday.
Comment 21 tim 2015-12-31 13:37:25 UTC
Thanks.
Comment 22 Caolán McNamara 2016-03-17 14:18:01 UTC
ORowSet::insertRow is called, that calls notifyAllListenersRowBeforeChange before it goes ahead and does the real insert there is some script listening on that and that calls close on the document again so eventually ORowSet::insertRow is called again. The inner insertRow completes and remove the m_pCache and eventually control returns to the outer one which falls over and dies.
Comment 23 Caolán McNamara 2016-03-17 14:18:50 UTC Comment hidden (obsolete)
Comment 24 Commit Notification 2016-03-17 14:55:56 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4331b137fdbe6992ca63ceb70a6f48ed6f9a86ea

Resolves: tdf#92617 don't crash if insertRow gets triggered during insertRow

It will be available in 5.2.0.

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 25 Caolán McNamara 2016-03-17 14:58:29 UTC
The specific example was reproducible and I've fixed our side. But all this does for you is to throw back to basic where this save-inside-a-save happens is which hopefully is useful for you to change your script to avoid this case.
Comment 26 Lionel Elie Mamane 2016-03-17 15:17:50 UTC
(In reply to tim from comment #4)

> I am in one form's (A) subform (B).  From there I open another form (C) that
> contains a subform (D).  

> If the focus is on subform (D) when form (C) is closed then tracing my
> macros I get to form D's afterupdate macro which seems to execute OK (all
> the values look to be correct) but on ending that macro Base crashes.

> If I manually move the focus from (D) to (C) before closing (C) then no
> crash occurs.

Reading from what Caolan explains, I think that is because moving the focus from (D) to (C) does the row insertion. You will find that clicking on the "save record" button should have the same effect.
Comment 27 Lionel Elie Mamane 2016-03-17 15:28:11 UTC
(In reply to Lionel Elie Mamane from comment #26)
> (In reply to tim from comment #4)
> 
> > I am in one form's (A) subform (B).  From there I open another form (C) that
> > contains a subform (D).  
> 
> > If the focus is on subform (D) when form (C) is closed then tracing my
> > macros I get to form D's afterupdate macro which seems to execute OK (all
> > the values look to be correct) but on ending that macro Base crashes.
> 
> > If I manually move the focus from (D) to (C) before closing (C) then no
> > crash occurs.
> 
> Reading from what Caolan explains, I think that is because moving the focus
> from (D) to (C) does the row insertion. You will find that clicking on the
> "save record" button should have the same effect.

You could also try to commit the changes (do the write to database) from the ExitTable3 macro before calling oController.close().

I'm not yet convinced this is not our bug. You shouldn't have to take these precautions. It should just work. I'm looking into it.
Comment 28 Lionel Elie Mamane 2016-03-17 15:59:50 UTC
Caolan, I think we will have the same problem with ORowSet::updateRow.
Comment 29 Lionel Elie Mamane 2016-03-17 16:21:57 UTC
So, what happens is:

 * focus is in table4 subform
 * you click on "exit" button which is in table3 form
 * this moves the focus to table3 form, which implicitly commits the changes
   in the table4 subform *before* allowing the click.
 * the commit of the changes calls your Table4BeforeUpdate macro
 * this macro contains a "wait" statement. This wait statement
   (which is a thread yield, that allows other events to be processed
    in the meantime) allows the "click" event to be processed, calling
   your ExitTable3 macro, which calls close, which starts the "commit
   changes" again.

This is definitely our bug. What I would like is for the "click" event *not* to be treated before the "commit because we change focus" is *finished*. I'm not 100% sure how to achieve that.
Comment 30 Lionel Elie Mamane 2016-03-17 17:04:13 UTC
At first I thought this could be linked to the svxform::FormScriptListener::impl_allowAsynchonousCall_nothrow discussed in bug 63398, but it looks like it is not.

Anybody has any idea of how I can enforce that one event "waits" for the other to finish?

I attach a backtrace.

At frame 80 starts the treatment of "change focus from one form to another":

#80 0x00007f469e84c4c7 in svxform::FormController::OnActivated (this=this@entry=0x769aae0)
    at /home/master/src/libreoffice/workdirs/libreoffice-5-2/svx/source/form/formcontroller.cxx:1763

On frames 74 and 73 you see that the change of focus first makes the "commit the current record".

#73 0x00007f469e886df7 in svx::FormControllerHelper::commitCurrentRecord (this=0x7b470f0)
    at /home/master/src/libreoffice/workdirs/libreoffice-5-2/svx/source/form/formcontrolling.cxx:306
#74 0x00007f469e7d537b in FmXFormShell::setActiveController (this=this@entry=0x322af50, 
    xController=uno::Reference to (svxform::FormController *) 0x769ab30, _bNoSaveOldContent=_bNoSaveOldContent@entry=false)
    at /home/master/src/libreoffice/workdirs/libreoffice-5-2/svx/source/form/fmshimp.cxx:1881

This then calls the event listeners, which are allowed to veto the commit (approveRowChange event). This goes in Basic interpreter code (frames 49 and below). When Basic gets to the "wait" statement (frame 29) it calls Application::Yield() (frame 28) which then starts treating the "click on button" event (frames 17 and below):

#13 0x00007f4638b4028f in frm::OButtonControl::OnClick (this=this@entry=0x797fb10)
    at /home/master/src/libreoffice/workdirs/libreoffice-5-2/forms/source/component/Button.cxx:460
(...)
#16 0x00007f469b4c2de6 in ImplHandleUserEvent (pSVEvent=pSVEvent@entry=0x7a99270)
    at /home/master/src/libreoffice/workdirs/libreoffice-5-2/vcl/source/window/winproc.cxx:1959

I want that the "OnClick" of the button that is in the form IS NOT TREATED before the "activation handlers" of the form THAT THIS BUTTON IS IN (called in formcontroller.cxx line 1734) are finished executing.


    if ( bActivated )
    {
        // (asynchronously) call activation handlers
        m_aActivationEvent.Call();

        // call modify listeners
        if ( m_bModified )
            m_aModifyListeners.notifyEach( &XModifyListener::modified, EventObject( *this ) );
    }


Any suggestion from the experts?
Comment 31 Lionel Elie Mamane 2016-03-17 17:05:14 UTC
Created attachment 123669 [details]
backtrace mentioned in comment 30
Comment 32 tim 2016-07-16 10:45:36 UTC
Using Version: 5.2.0.1 Build ID: 1:5.2.0~rc1-0ubuntu1~xenial1
CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; 
Locale: en-GB (en_GB.UTF-8)

I re-ran this test, and now get a Basic runtime error:

"BASIC runtime error.
An exception occurred 
Type: com.sun.star.uno.RuntimeException
Message: C++ code threw St13runtime_error: recursion in insertRow"

This happens when I close oController in the subroutine below.

Sub ExitTable3 (oEV as Object)	
	Dim oController As Object
	Dim oForm as Object

	' Save the value of id3

	Set oForm = oEV.Source.Model.Parent
	gbid3value = oForm.getByName("id3").Text
	
	Set oController = Thisdatabasedocument.getFormDocuments.getByName("Table3")
	oController.close()
	
End Sub

On one occasion this was followed by a Base crash.
Comment 33 Alex Thurgood 2016-08-29 14:12:53 UTC
(In reply to tim from comment #32)

Hi Tim,


> Using Version: 5.2.0.1 Build ID: 1:5.2.0~rc1-0ubuntu1~xenial1
> CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; 
> Locale: en-GB (en_GB.UTF-8)
> 
> I re-ran this test, and now get a Basic runtime error:
> 
> "BASIC runtime error.
> An exception occurred 
> Type: com.sun.star.uno.RuntimeException
> Message: C++ code threw St13runtime_error: recursion in insertRow"
> 

That error message seems to be appropriate to the situation described by Caolan after his fix was applied in comment 25. In other words, the app doesn't crash immediately, but returns an error because insertRow() is being nested within an already running insertRow().

As Lionel has also indicated in his comment 28, a similar problem occurs with updateRow() which gets called.
Comment 34 Alex Thurgood 2016-08-29 14:18:26 UTC
@Tim :fwiw, I can confirm the Basic error message that you reported :
BASIC runtime error.
An exception occurred 
Type: com.sun.star.uno.RuntimeException
Message: C++ code threw St13runtime_error: recursion in insertRow.

on OSX 10.11.6
Version: 5.3.0.0.alpha0+
Build ID: 03f576466c9f110fbef8923604908654d59484a6
CPU Threads: 2; OS Version: Mac OS X 10.11.6; UI Render: default; 
Locale: fr-FR (fr.UTF-8); Calc: group
Comment 35 Alex Thurgood 2016-08-29 14:25:11 UTC
The Basic code throws other error messages which cause the Basic IDE to be displayed, which then caused a mutexlock (app hangs) because I'd already closed Forms Table1 and Table3 - sigh.
Comment 36 Alex Thurgood 2016-08-29 14:40:48 UTC
@Tim : if I remove the wait statement, I don't get any error messages any more, or any other visible Basic issues and data entry in your forms seems to work fine.
Comment 37 tim 2016-08-29 15:04:40 UTC
(In reply to Alex Thurgood from comment #36)
> @Tim : if I remove the wait statement, I don't get any error messages any
> more, or any other visible Basic issues and data entry in your forms seems
> to work fine.

Thanks for keeping at this one!

I have gone back to my (stupidly complex) original source of this problem and taken out the work-around I put in place to stop crashes.  The work-around was to refuse to exit the whole form (done by selecting a button on the form) when the focus was in the sub-form, and just put the focus on a field in the main form instead.  The user then had to exit the form by pressing the button again.

So I took out the work-around, and now it works as it should!

I'm now on Version: 5.2.1.1
Build ID: 1:5.2.1~rc1-0ubuntu1~xenial0
CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; 
Locale: en-GB (en_GB.UTF-8); Calc: group

I'll be using my application for real (as opposed to a slightly artificial test mode) again in a few days time.  If all goes well without the work-around I'll close the report, marking it fixed.

Is that OK?

Thanks to all....
Comment 38 Alex Thurgood 2016-08-30 08:07:53 UTC
(In reply to tim from comment #37)


> I'll be using my application for real (as opposed to a slightly artificial
> test mode) again in a few days time.  If all goes well without the
> work-around I'll close the report, marking it fixed.
> 
> Is that OK?
> 
> Thanks to all....

Unless Lionel wants to keep this open to explore the asynchronous call/yield problem, then I guess so.
Comment 39 tim 2016-08-31 08:28:48 UTC
I've tested this again on my full system.
If I save the subform before attempting to exit the form all is OK.

If I don't, and BASE asks me if I want to save the form first, I get:

BASIC runtime error.
An exception occurred 
Type: com.sun.star.uno.RuntimeException
Message: C++ code threw St13runtime_error: recursion in insertRow
Comment 40 Xisco Faulí 2016-09-12 12:32:02 UTC
Adding keyword 'bibisectRequest'.
Comment 41 Buovjaga 2018-05-24 11:33:15 UTC
Does not make sense to keep bibisectRequest - it crashes with 3.6.7.2 on Linux and 4.3.0 beta1 on Win with the steps in comment 5