Problem description: On pc Debian x86-64 with master sources updated today and a brand new LO profile, I tried to reproduce fdo#64024 and had a crash Steps to reproduce: 1. Open Writer 2. Menu Tools/Mail Merge Wizard 3. Click "Next" twice => you'll be at step 3 4. Click on button "Select Address List" Current behavior: Crash Expected behavior: No crash Operating System: Debian Version: 4.1.0.0.alpha0+ Master
Created attachment 78885 [details] console + bt with symbols on master sources Here's the bt + console logs
Caolán: there's vcl part in bt Lionel: this may interest you: warn:legacy.osl:7761:1:sw/source/ui/dbui/mmconfigitem.cxx:928: exception caught in: SwMailMergeConfigItem::GetResultSet() warn:legacy.osl:7761:1:sw/source/ui/dbui/dbmgr.cxx:1628: Exception in SwDBMgr::GetColumnSupplier warn:legacy.osl:7761:1:sw/source/ui/dbui/mmconfigitem.cxx:928: exception caught in: SwMailMergeConfigItem::GetResultSet() warn:dbaccess:7761:1:dbaccess/source/core/api/SingleSelectQueryComposer.cxx:937: We have column labels for *some* columns but not all I don't know if these 2 parts are linked. If a separated bug is needed, tell me, I'll create it.
This is a crash from the assert, so it only happens in a debug version. i.e. if you comment out the assert in vcl/source/app/dbggui.cxx:1751 the it'll not crash. The right fix (IIRC) is to put a SolarMutexGuard aSolarGuard somewhere in that bt, where though is another question.
Since nothing is happening around this and triggered debug aborts *really* get in the way of dogfooding dbgutils builds, I just put it "somewhere". Caolán or *anybody*, if you disagree with my decision, just change it for the better. The only code I dared touch is mailmerge-specific code; anything else needs a better understanding of the architecture than I have. So this basically limits us to the following stack frames (from my own backtrace, not the one of Julien): #29 0x00007fe3eda4e813 in SwMailMergeWizard::StartExecuteModal (this=0x5387010, rEndDialogHdl=...) at /home/master/src/libreoffice/workdirs/libreoffice-4.1/sw/source/ui/dbui/mailmergewizard.cxx:299 #30 0x00007fe3ed8dccb0 in AbstractMailMergeWizard_Impl::StartExecuteModal (this=0x4d6b890, rEndDialogHdl=...) at /home/master/src/libreoffice/workdirs/libreoffice-4.1/sw/source/ui/dialog/swdlgfact.cxx:592 #31 0x00007fe3fa004f25 in (anonymous namespace)::SwMailMergeWizardExecutor::ExecuteWizard (this=0x3e9f4e0) at /home/master/src/libreoffice/workdirs/libreoffice-4.1/sw/source/ui/app/apphdl.cxx:388 #32 0x00007fe3fa004c5e in (anonymous namespace)::SwMailMergeWizardExecutor::ExecuteMailMergeWizard (this=0x3e9f4e0, pArgs=pArgs@entry=0x0) at /home/master/src/libreoffice/workdirs/libreoffice-4.1/sw/source/ui/app/apphdl.cxx:369 Below that is VCL's Dialog::StartExecuteModal and above that is some generic "SwModule::ExecOther" which (I guess) cannot know whether the stuff it calls needs SolarMutex or not. So I took the lowest frame, to insure against the case that any other code path calls SwMailMergeWizard::StartExecuteModal without going through the higher-ups in this backtrace. It is unclear whether this fixes Julien's scenario, but <shrug>.
Created attachment 81805 [details] Lionel backtrace (immediately on menu Tools / Mail merge wizard)
Created attachment 81806 [details] Lionel backtrace (when click on "select address book" button)
Created attachment 81812 [details] console output Note the "SalYieldMutex::release() called with zero count"
I now get ~the same backtrace as Julien. I tried to apply the same methodology (put it in the only mailmerge-specific code in the backtrace), but it *still* aborts with the same backtrace. Something somewhere must be releasing the solar mutex :-( I give up.
Created attachment 81820 [details] not completely working patch Here's the patch I tried. Solves my first backtrace, but does not prevent my second (= Julien's).
On pc Debian x86-64 with LO 4.2.5 Debian package, I don't reproduce this. I don't reproduce this too with master sources updated today (still in debug mode). =>WFM