I have taken the liberty of copying the email addresses from #70703 to this report.

Created attachment 117120 [details]
hs_err_pid file

I just found a related java error log, attached.

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

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.

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.

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

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>

Created attachment 117189 [details]
backtrace

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.

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

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.

Created attachment 117926 [details]
console logs + bt with debug symbols

On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.

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

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

Created attachment 117928 [details]
valgrind log

In addition of Valgrind trace, I added some traces at DELETEZ(m_pCache) and at m_pCache = new...

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?

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!

Is there any more on this?  I still get these crashes at times.

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.

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.

Thanks.

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.

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.

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.

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

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

Caolan, I think we will have the same problem with ORowSet::updateRow.

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.

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?

Created attachment 123669 [details]
backtrace mentioned in comment 30

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.

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

@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

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.

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

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

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

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

Adding keyword 'bibisectRequest'.

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

Using comment 5 steps, getting the BASIC runtime error as described in comment 32.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 2f5ab5b8e7bd7dd06e00153abb77a69e5d192dd2
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: CL threaded

@Lionel, are you able to provide modified steps that still produce a crash? Would be good also to clarify to summary.