Now that LibreOffice can be built with Firebird3 integration on OSX, I thought I would try creating a FB3 embedded ODB file. However, when reaching the last step of the DB creation wizard, where a file name is entered and Save button is pressed, the app SIGABRTs.
Backtrace included from my master debug build. The trace seems to indicate a mutex release problem.
Steps to Reproduce:
1. Create a new embedded Firebird3 embedded ODB file using the DB creation wizard.
2. At the penultimate step of saving the file, enter a file name and click on the Save button.
3. Watch LO die (spinning beach ball mode outside of a lldb debug session requiring forced kill, and SIGABRT from within lldb)
LO should save the file and open the file allowing for further work.
User Profile Reset: No
If you kill the app, or as in the case of a lldb session, the app SIGABRTs, the file that was just created refuses to load in LO once restarted, leading to a limbo state where nothing in the app responds.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0
Created attachment 128981 [details]
backtrace from lldb debugging session
For the test, could you comment DBG_TESTSOLARMUTEX() line in Scheduler::CalculateMinimumTimeout function (see http://opengrok.libreoffice.org/xref/core/vcl/source/app/scheduler.cxx#203), then run "make vcl.build" and give a new try?
(In reply to Julien Nabet from comment #2)
> For the test, could you comment DBG_TESTSOLARMUTEX() line in
> Scheduler::CalculateMinimumTimeout function (see
> then run "make vcl.build" and give a new try?
Commenting out the DBG test allowed the file save operation to complete, but the app still hangs with the ODB main container window now displayed. I can move the ODB main window around, but none of the buttons or menu entries are active.
Setting to new as the change suggested by Julien showed that the problem was real.
When running in lldb, after your suggested change, I see this :
Process 19454 launched: '/Volumes/BUILDHD/Shared/LO/core/instdir/LibreOfficeDev.app/Contents/MacOS/soffice' (x86_64)
warn:legacy.osl:19454:1:svtools/source/uno/genericunodialog.cxx:314: OGenericUnoDialog::OnDialogDying: where does this come from?
Assertion failed: (ImplGetSVData()->mpDefInst->CheckYieldMutex() && "SolarMutex not locked"), function ImplDbgTestSolarMutex, file /Volumes/BUILDHD/Shared/LO/core/vcl/source/app/dbggui.cxx, line 47.
Process 19454 stopped
* thread #48: tid = 0x407294, 0x00007fffa71e5dda libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
frame #0: 0x00007fffa71e5dda libsystem_kernel.dylib`__pthread_kill + 10
-> 0x7fffa71e5dda <+10>: jae 0x7fffa71e5de4 ; <+20>
0x7fffa71e5ddc <+12>: movq %rax, %rdi
0x7fffa71e5ddf <+15>: jmp 0x7fffa71ded6f ; cerror_nocancel
0x7fffa71e5de4 <+20>: retq
(In reply to Alex Thurgood from comment #5)
> When running in lldb, after your suggested change, I see this :
I would add that in the lldb session, the Save dialog still doesn't shut, whereas if I just run the LO app from instdir, it does save the file, and leads to the situation described in comment 3
Created attachment 128988 [details]
bt after commenting out suggested line in scheduler.cxx
Alex: just realized it's a dup of mine :)
If I'm wrong or missed something, don't hesite to revert this.
*** This bug has been marked as a duplicate of bug 103667 ***
*** This bug has been marked as a duplicate of bug 103515 ***