Created attachment 80433 [details]
console + bt with symbols on master sources

bt attached

Lionel: there it is, as you asked about on https://bugs.freedesktop.org/show_bug.cgi?id=61725#c21 :-)

Confirmed using Linux Mint 15 x64 with LibreOffice Version: 4.2.0.0.alpha0+
Build ID: 55ff402fa24bcf9478e7fde94f2ab57c2223b7f

It already crashes when I click 'Next' here, after I double clicked on ContactID.

Kind regards and thanks for your great QA work Julien :-)!
Joren

(In reply to comment #3)
> Confirmed using Linux Mint 15 x64 with LibreOffice Version: 4.2.0.0.alpha0+
> Build ID: 55ff402fa24bcf9478e7fde94f2ab57c2223b7f
> 
> It already crashes when I click 'Next' here, after I double clicked on
> ContactID.

That is most likely a different problem, esp. since 55ff402fa24bcf9478e7fde94f2ab57c2223b7f is past e57eeb6d5f547a4a49df796641141c733f6c5204 which was the fix for bug 65168.  That is, comment 0 of this bug is about the scenario using the legacy, Writer-based report wizard when the Report Builder is not (properly) installed, cf. attachment 80411 [details].  The crash you are observing is likely in a scenario using the Report Builder wizard, cf. attachment 80414 [details].

@jorendc:  Can you confirm the above?  If yes, please file a new issue for the crash you observe, and ideally add a backtrace.

(I'm going to add notes here shortly on the cause of the originally reported crash.)

Concentrating back on the crash reported in comment 0 of this bug:

I can reproduce that problem with a LO installation that does not use the Report Builder, but rather the legacy, Writer-based report wizard (cf. attachment 80411 [details]; as e.g., happened by accident on master before bug 65168 got fixed, or would happen in a --disable-report-builder build, or if explicitly leaving out installation of the Report Builder component for installation sets that support that, like on Windows).  It involves a Java finalizer, which is executed at an unpredictable time, so does not necessarily happen always, though.

The ref-counted UNO object SwXTextField dervies from SwClient, where SwModify holds a list of chained SwClient instances by naked pointers.  ~SwClient removes itself from that list.  Modifications of SwModify's list apparently need to be done with the solar mutex locked, but the Java finalizer thread

> #0  SwXTextField::~SwXTextField (this=0x7fff9800c808, __in_chrg=<optimized out>) at lo/core/sw/source/core/unocore/unofield.cxx:1155
> #1  0x00007fff9a0d9df8 in SwXTextField::~SwXTextField (this=0x7fff9800c808, __in_chrg=<optimized out>) at lo/core/sw/source/core/unocore/unofield.cxx:1164
> #2  0x00007ffff6b160f2 in cppu::OWeakObject::release (this=0x7fff9800c808) at lo/core/cppuhelper/source/weak.cxx:204
> #3  0x00007fff9a0e714c in cppu::WeakImplHelper5<com::sun::star::text::XDependentTextField, com::sun::star::lang::XServiceInfo, com::sun::star::beans::XPropertySet, com::sun::star::lang::XUnoTunnel, com::sun::star::util::XUpdatable>::release (this=0x7fff9800c808) at lo/core/include/cppuhelper/implbase5.hxx:110
> #4  0x00007fffe427dfe0 in bridges::cpp_uno::shared::freeUnoInterfaceProxy (pEnv=0x1ac89d0, pProxy=0x243b330) at lo/core/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:43
> #5  0x00007ffff6e0b5ac in (anonymous namespace)::s_stub_defenv_revokeInterface (pParam=0x7fff9b614688) at lo/core/cppu/source/uno/lbenv.cxx:390
> #6  0x00007ffff6e071ba in s_environment_invoke_v (pCurrEnv=0x0, pTargetEnv=0x1ac89d0, pCallee=0x7ffff6e0b28e <(anonymous namespace)::s_stub_defenv_revokeInterface(va_list*)>, pParam=0x7fff9b614688) at lo/core/cppu/source/uno/EnvStack.cxx:292
> #7  0x00007ffff6e07262 in uno_Environment_invoke_v (pTargetEnv=0x1ac89d0, pCallee=0x7ffff6e0b28e <(anonymous namespace)::s_stub_defenv_revokeInterface(va_list*)>, pParam=0x7fff9b614688) at lo/core/cppu/source/uno/EnvStack.cxx:311
> #8  0x00007ffff6e07322 in uno_Environment_invoke (pEnv=0x1ac89d0, pCallee=0x7ffff6e0b28e <(anonymous namespace)::s_stub_defenv_revokeInterface(va_list*)>) at lo/core/cppu/source/uno/EnvStack.cxx:320
> #9  0x00007ffff6e0b988 in (anonymous namespace)::defenv_revokeInterface (pEnv=0x1ac89d0, pInterface=0x243b5a0) at lo/core/cppu/source/uno/lbenv.cxx:446
> #10 0x00007fffe427e105 in bridges::cpp_uno::shared::releaseProxy (pUnoI=0x243b5a0) at lo/core/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:85
> #11 0x00007fffcd28e6b4 in Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_finalize (jni_env=0x7fff480019d8, jo_proxy=0x7fff9b6148c0, bridge_handle=28084016) at lo/core/bridges/source/jni_uno/jni_java2uno.cxx:679
> #12 0x00007fffc0e08f90 in ?? ()
> #13 0x00007fff48001800 in ?? ()
> #14 0x00007fffcc987c23 in ConstantPoolCacheEntry::set_method (this=0x5ff5059b0, invoke_code=Bytecodes::_nop, method=..., vtable_index=<optimized out>) at /usr/src/debug/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/oops/cpCacheOop.cpp:215
> #15 0x00007fffc0dfd158 in ?? ()
> #16 0x0000000000000000 in ?? ()

calls ~SwXTextField without the solar mutex locked.  That thread can get blocked when the SwTextField's member sw::UnoImplPtr<Impl> m_pImpl is destroyed and ~UnoImplPtr tries to lock the solar mutex ("SolarMutexGuard g;" at sw/inc/unobaseclass.hxx:110) while the main thread (with solar mutex locked) is proceeding to

> #0  SwXTextField::~SwXTextField (this=0x7fff9800c808, __in_chrg=<optimized out>) at lo/core/sw/source/core/unocore/unofield.cxx:1164
> #1  0x00007ffff6b160f2 in cppu::OWeakObject::release (this=0x7fff9800c808) at lo/core/cppuhelper/source/weak.cxx:204
> #2  0x00007fff9a0e714c in cppu::WeakImplHelper5<com::sun::star::text::XDependentTextField, com::sun::star::lang::XServiceInfo, com::sun::star::beans::XPropertySet, com::sun::star::lang::XUnoTunnel, com::sun::star::util::XUpdatable>::release (this=0x7fff9800c808) at lo/core/include/cppuhelper/implbase5.hxx:110
> #3  0x00007fff99904d1d in com::sun::star::uno::Reference<com::sun::star::uno::XInterface>::~Reference (this=0x7fffffffc320, __in_chrg=<optimized out>) at lo/core/include/com/sun/star/uno/Reference.hxx:108
> #4  0x00007fff99904504 in com::sun::star::lang::EventObject::~EventObject (this=0x7fffffffc320, __in_chrg=<optimized out>) at lo/core/workdir/unxlngx6/UnoApiHeadersTarget/udkapi/normal/com/sun/star/lang/EventObject.hdl:18
> #5  0x00007fff9a0e06ad in SwXTextField::Invalidate (this=0x7fff9800c808) at lo/core/sw/source/core/unocore/unofield.cxx:2388
> #6  0x00007fff9a0e0763 in SwXTextField::Modify (this=0x7fff9800c808, pOld=0x7fffffffc460, pNew=0x7fffffffc460) at lo/core/sw/source/core/unocore/unofield.cxx:2400
> #7  0x00007fff9997a588 in SwModify::ModifyBroadcast (this=0x2262610, pOldValue=0x7fffffffc460, pNewValue=0x7fffffffc460, nType=0x7fff99979830 <SwClient::CreateType()>) at lo/core/sw/source/core/attr/calbck.cxx:357
> #8  0x00007fff99979fdc in SwModify::NotifyClients (this=0x2262610, pOldValue=0x7fffffffc460, pNewValue=0x7fffffffc460) at lo/core/sw/source/core/attr/calbck.cxx:196
> #9  0x00007fff99979db0 in SwModify::~SwModify (this=0x2262610, __in_chrg=<optimized out>) at lo/core/sw/source/core/attr/calbck.cxx:141
> #10 0x00007fff99979e22 in SwModify::~SwModify (this=0x2262610, __in_chrg=<optimized out>) at lo/core/sw/source/core/attr/calbck.cxx:149
> #11 0x00007fff99b0fe82 in SwDoc::~SwDoc (this=0x225b820, __in_chrg=<optimized out>) at lo/core/sw/source/core/doc/docnew.cxx:506
> #12 0x00007fff99b1194c in SwDoc::~SwDoc (this=0x225b820, __in_chrg=<optimized out>) at lo/core/sw/source/core/doc/docnew.cxx:694
> #13 0x00007fff9a3990fe in SwDocShell::RemoveLink (this=0x2250000) at lo/core/sw/source/ui/app/docshini.cxx:456
> #14 0x00007fff9a39897f in SwDocShell::~SwDocShell (this=0x2250000, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at lo/core/sw/source/ui/app/docshini.cxx:375
> #15 0x00007fff9a398ad4 in SwDocShell::~SwDocShell (this=0x2250000, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at lo/core/sw/source/ui/app/docshini.cxx:383
> #16 0x00007ffff4060d42 in SvRefBase::QueryDelete (this=0x2250170) at lo/core/tools/source/ref/ref.cxx:29
> #17 0x00007ffff59b3889 in SvRefBase::ReleaseReference (this=0x2250170) at lo/core/include/tools/ref.hxx:188
> #18 0x00007ffff59b3997 in SfxObjectShellRef::~SfxObjectShellRef (this=0x7fffffffcb90, __in_chrg=<optimized out>) at lo/core/include/sfx2/objsh.hxx:779
> #19 0x00007ffff5dce46f in SfxViewFrame::ReleaseObjectShell_Impl (this=0x22cea10) at lo/core/sfx2/source/view/viewfrm.cxx:1120
> #20 0x00007ffff5dcfa32 in SfxViewFrame::~SfxViewFrame (this=0x22cea10, __in_chrg=<optimized out>) at lo/core/sfx2/source/view/viewfrm.cxx:1485
> #21 0x00007ffff5dcfc90 in SfxViewFrame::~SfxViewFrame (this=0x22cea10, __in_chrg=<optimized out>) at lo/core/sfx2/source/view/viewfrm.cxx:1506
> #22 0x00007ffff5dce673 in SfxViewFrame::Close (this=0x22cea10) at lo/core/sfx2/source/view/viewfrm.cxx:1145
> #23 0x00007ffff5da48d2 in SfxFrame::DoClose_Impl (this=0x22a73e0) at lo/core/sfx2/source/view/frame.cxx:175
> #24 0x00007ffff5dc03b1 in SfxBaseController::dispose (this=0x7fff980e7248) at lo/core/sfx2/source/view/sfxbasecontroller.cxx:1035
> #25 0x00007fffe1099cea in framework::Frame::setComponent (this=0x7fffa0dc5548, xComponentWindow=empty uno::Reference, xController=empty uno::Reference) at lo/core/framework/source/services/frame.cxx:1357
> #26 0x00007fffe109a92b in framework::Frame::close (this=0x7fffa0dc5548, bDeliverOwnership=0 '\000') at lo/core/framework/source/services/frame.cxx:1610
> #27 0x00007fffe0fb67d4 in framework::pattern::frame::closeIt (xResource=uno::Reference to (framework::Frame *) 0x7fffa0dc5570, bDelegateOwnership=0 '\000') at lo/core/framework/source/inc/pattern/frame.hxx:83
> #28 0x00007fffe0fb5a4b in framework::CloseDispatcher::implts_closeFrame (this=0x7fff931c9790) at lo/core/framework/source/dispatch/closedispatcher.cxx:519
> #29 0x00007fffe0fb5280 in framework::CloseDispatcher::impl_asyncCallback (this=0x7fff931c9790) at lo/core/framework/source/dispatch/closedispatcher.cxx:379
> #30 0x00007fffe0fb4f1b in framework::CloseDispatcher::LinkStubimpl_asyncCallback (pThis=0x7fff931c9790, pCaller=0x0) at lo/core/framework/source/dispatch/closedispatcher.cxx:265
> #31 0x00007ffff2b9ca66 in Link::Call (this=0x7fff931c9808, pCaller=0x0) at lo/core/include/tools/link.hxx:123
> #32 0x00007ffff2fd19a4 in vcl::EventPoster::DoEvent_Impl (this=0x7fff931c9800, pEvent=0x0) at lo/core/vcl/source/helper/evntpost.cxx:47
> #33 0x00007ffff2fd1913 in vcl::EventPoster::LinkStubDoEvent_Impl (pThis=0x7fff931c9800, pCaller=0x0) at lo/core/vcl/source/helper/evntpost.cxx:50
> #34 0x00007ffff2b9ca66 in Link::Call (this=0x20c3130, pCaller=0x0) at lo/core/include/tools/link.hxx:123
> #35 0x00007ffff31569fd in ImplHandleUserEvent (pSVEvent=0x2157d10) at lo/core/vcl/source/window/winproc.cxx:1986
> #36 0x00007ffff3157ed9 in ImplWindowFrameProc (pWindow=0x1406a40, nEvent=22, pEvent=0x2157d10) at lo/core/vcl/source/window/winproc.cxx:2601
> #37 0x00007ffff3165ff7 in SalFrame::CallCallback (this=0x1406f30, nEvent=22, pEvent=0x2157d10) at lo/core/vcl/inc/salframe.hxx:243
> #38 0x00007ffff3165a96 in SalGenericDisplay::DispatchInternalEvent (this=0x6b15e0) at lo/core/vcl/generic/app/gendisp.cxx:91
> #39 0x00007fffe547975a in GtkData::userEventFn (data=0x6225a0) at lo/core/vcl/unx/gtk/app/gtkdata.cxx:935
> #40 0x00007fffe54797b5 in call_userEventFn (data=0x6225a0) at lo/core/vcl/unx/gtk/app/gtkdata.cxx:945
> #41 0x0000003222c47a55 in g_main_dispatch (context=0x65b230) at gmain.c:2715
> #42 g_main_context_dispatch (context=context@entry=0x65b230) at gmain.c:3219
> #43 0x0000003222c47d88 in g_main_context_iterate (context=context@entry=0x65b230, block=block@entry=0, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3290
> #44 0x0000003222c47e44 in g_main_context_iteration (context=0x65b230, may_block=0) at gmain.c:3351
> #45 0x00007fffe5478682 in GtkData::Yield (this=0x6225a0, bWait=true, bHandleAllCurrentEvents=false) at lo/core/vcl/unx/gtk/app/gtkdata.cxx:574
> #46 0x00007fffe547c142 in GtkInstance::Yield (this=0x622340, bWait=true, bHandleAllCurrentEvents=false) at lo/core/vcl/unx/gtk/app/gtkinst.cxx:404
> #47 0x00007ffff2bb6765 in ImplYield (i_bWait=true, i_bAllEvents=false) at lo/core/vcl/source/app/svapp.cxx:422
> #48 0x00007ffff2bb2d75 in Application::Yield (i_bAllEvents=false) at lo/core/vcl/source/app/svapp.cxx:456
> #49 0x00007ffff2bb2d1c in Application::Execute () at lo/core/vcl/source/app/svapp.cxx:401
> #50 0x00007ffff7a8b6bc in desktop::Desktop::Main (this=0x7fffffffe360) at lo/core/desktop/source/app/app.cxx:1706
> #51 0x00007ffff2bbf39d in ImplSVMain () at lo/core/vcl/source/app/svmain.cxx:162
> #52 0x00007ffff2bbf49d in SVMain () at lo/core/vcl/source/app/svmain.cxx:198
> #53 0x00007ffff7ace0da in soffice_main () at lo/core/desktop/source/app/sofficemain.cxx:82
> #54 0x000000000040094c in sal_main () at lo/core/desktop/source/app/main.c:48
> #55 0x000000000040092d in main (argc=1, argv=0x7fffffffe548) at lo/core/desktop/source/app/main.c:47

That is, ~SwModify still finds the in-destruction SwXTextField SwClient instance in its list and notifies it.  SwXTextField::Invalidate creates a css::lang::EventObject from this, which resurrects the ref-count from 0 back to 1, which leads to a second call to ~SwXTextField when the EventObject goes out of scope.

One solution would be to lock the solar mutex in SwXTextField::release (only locking it in ~SwXTextField would be too late) like in the patch below, but a better approach would arguably be to properly fix the design of SwClient/SwModify.

> diff --git a/sw/source/core/inc/unofield.hxx b/sw/source/core/inc/unofield.hxx
> index f83fcd8..21f7f47 100644
> --- a/sw/source/core/inc/unofield.hxx
> +++ b/sw/source/core/inc/unofield.hxx
> @@ -120,15 +120,15 @@ public:
>  };
>  
>  struct SwFieldProperties_Impl;
> -class SwXTextField : public cppu::WeakImplHelper5
> +typedef cppu::WeakImplHelper5
>  <
>      ::com::sun::star::text::XDependentTextField,
>      ::com::sun::star::lang::XServiceInfo,
>      ::com::sun::star::beans::XPropertySet,
>      ::com::sun::star::lang::XUnoTunnel,
>      ::com::sun::star::util::XUpdatable
> ->,
> -            public SwClient
> +> SwXTextField_Base;
> +class SwXTextField : public SwXTextField_Base, public SwClient
>  {
>  
>  private:
> @@ -158,6 +158,7 @@ public:
>      SwXTextField(sal_uInt16 nServiceId, SwDoc* pDoc=0);
>      SwXTextField(const SwFmtFld& rFmt, SwDoc* pDoc);
>  
> +    virtual void SAL_CALL release() throw ();
>  
>      TYPEINFO();
>  
> diff --git a/sw/source/core/unocore/unofield.cxx b/sw/source/core/unocore/unofield.cxx
> index 9d0e282..72b08e0 100644
> --- a/sw/source/core/unocore/unofield.cxx
> +++ b/sw/source/core/unocore/unofield.cxx
> @@ -1163,6 +1163,12 @@ SwXTextField::~SwXTextField()
>      delete m_pProps;
>  }
>  
> +void SwXTextField::release() throw ()
> +{
> +    SolarMutexGuard g;
> +    SwXTextField_Base::acquire();
> +}
> +
>  void SwXTextField::attachTextFieldMaster(const uno::Reference< beans::XPropertySet > & xFieldMaster)
>                      throw( lang::IllegalArgumentException, uno::RuntimeException )
>  {

(In reply to comment #5)
> The ref-counted UNO object SwXTextField dervies from SwClient, where
> SwModify holds a list of chained SwClient instances by naked pointers. 
> ~SwClient removes itself from that list.  Modifications of SwModify's list
> apparently need to be done with the solar mutex locked, but the Java
> finalizer thread

right, that is broken by design; the sw UNO API implementation has this problem a lot; i once started fixing it but only got a part of it fixed (see CWS swunolocking1 and issue 105557 )

> calls ~SwXTextField without the solar mutex locked.  That thread can get
> blocked when the SwTextField's member sw::UnoImplPtr<Impl> m_pImpl is
> destroyed and ~UnoImplPtr tries to lock the solar mutex ("SolarMutexGuard
> g;" at sw/inc/unobaseclass.hxx:110) while the main thread (with solar mutex
> locked) is proceeding to

hmm... looks like that class is only partially converted - has the 
UnoImplPtr member but the Impl class does not derive SwClient yet.
i'll fix that when i find some time.

> > +void SwXTextField::release() throw ()
> > +{
> > +    SolarMutexGuard g;
> > +    SwXTextField_Base::acquire();
> > +}
> > +

surely release calling acquire is a typo?

(In reply to comment #6)
> > > +void SwXTextField::release() throw ()
> > > +{
> > > +    SolarMutexGuard g;
> > > +    SwXTextField_Base::acquire();
> > > +}
> > > +
> 
> surely release calling acquire is a typo?

Ach, of course.  But fixing that still keeps the problem from reappearing for me.

(In reply to comment #4)
> (In reply to comment #3)
> > Confirmed using Linux Mint 15 x64 with LibreOffice Version: 4.2.0.0.alpha0+
> > Build ID: 55ff402fa24bcf9478e7fde94f2ab57c2223b7f
> > 
> > It already crashes when I click 'Next' here, after I double clicked on
> > ContactID.
> 
> That is most likely a different problem, esp. since
> 55ff402fa24bcf9478e7fde94f2ab57c2223b7f is past
> e57eeb6d5f547a4a49df796641141c733f6c5204 which was the fix for bug 65168. 
> That is, comment 0 of this bug is about the scenario using the legacy,
> Writer-based report wizard when the Report Builder is not (properly)
> installed, cf. attachment 80411 [details].  The crash you are observing is
> likely in a scenario using the Report Builder wizard, cf. attachment 80414 [details]
> [details].
> 
> @jorendc:  Can you confirm the above?  If yes, please file a new issue for
> the crash you observe, and ideally add a backtrace.

I can reproduce a crash there with a current (using the Report Builder) --enable-dbgutil master build from a fired DbgTestSolarMutex assertion; I can not reproduce any problem with a current --disable-dbgutil master build (where that assertion is not active); fixed that with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=85165a18e9f8123d80246bedfad0acd8a314f715> "Lock Solar Mutex in rptui::OSectionWindow::_propertyChanged" (the commit message contains the relevant backtrace).

@jorendc:  Do you know whether the "LibreOffice Version: 4.2.0.0.alpha0+ Build ID: 55ff402fa24bcf9478e7fde94f2ab57c2223b7f" you were testing with was an --enable-dbgutil (or --enable-debug) build?

(In reply to comment #8)
> @jorendc:  Do you know whether the "LibreOffice Version: 4.2.0.0.alpha0+
> Build ID: 55ff402fa24bcf9478e7fde94f2ab57c2223b7f" you were testing with was
> an --enable-dbgutil (or --enable-debug) build?

Sorry for my late answer, and the fact I can't test on Linux Mint right now (don't have access, Mac OSX for now). 

But to provide an answer to your question: Yes, it is an --enable-debug --enable-dbgutil build (don't know that's a bit overkill, but I have both :) ).

Thanks for your time testing this extensively.

Kind regards,
Joren

SwXTextField crash in the backtrace should be fixed now.

don't know how to start this "legacy" report-designer - i always get the "Report Builder" java thing.

Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=15f431e595d0e0bd24ab185ab552d39a56d55986

fdo#65478, i#105557: thread safety of SwXTextField



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.

Michael: Lionel had recently put some information about legacy reportbuilder and new one. Badfully, I don't remember where is it but it could be interesting to have it on some wiki page.

Anyway, I'll git update my local repo and give it a new try to verify all this tomorrow I think (since I git update generally in the morning), meanwhile, thank you all for your support about this tracker.

can no longer reproduce the crash with my recent --disable-report-builder master build