Bug 104138 - CRASH - SIGABRT when attempting to create Firebird3 ODB file - mutex release problem
Summary: CRASH - SIGABRT when attempting to create Firebird3 ODB file - mutex release ...
Status: RESOLVED DUPLICATE of bug 103515
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha1+
Hardware: x86-64 (AMD64) macOS (All)
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace
Depends on:
Blocks:
 
Reported: 2016-11-24 08:53 UTC by Alex Thurgood
Modified: 2017-10-28 18:23 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
backtrace from lldb debugging session (67.78 KB, text/plain)
2016-11-24 08:56 UTC, Alex Thurgood
Details
bt after commenting out suggested line in scheduler.cxx (50.86 KB, text/plain)
2016-11-24 11:11 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2016-11-24 08:53:40 UTC
Description:
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)

Actual Results:  
LO SIGABRTs

Expected Results:
LO should save the file and open the file allowing for further work.


Reproducible: Always

User Profile Reset: No

Additional Info:
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
Comment 1 Alex Thurgood 2016-11-24 08:56:46 UTC
Created attachment 128981 [details]
backtrace from lldb debugging session
Comment 2 Julien Nabet 2016-11-24 09:55:34 UTC
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?
Comment 3 Alex Thurgood 2016-11-24 10:55:32 UTC
(In reply to Julien Nabet from comment #2)
> 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?

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.
Comment 4 Alex Thurgood 2016-11-24 10:56:38 UTC
Setting to new as the change suggested by Julien showed that the problem was real.
Comment 5 Alex Thurgood 2016-11-24 11:01:26 UTC
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
libsystem_kernel.dylib`__pthread_kill:
->  0x7fffa71e5dda <+10>: jae    0x7fffa71e5de4            ; <+20>
    0x7fffa71e5ddc <+12>: movq   %rax, %rdi
    0x7fffa71e5ddf <+15>: jmp    0x7fffa71ded6f            ; cerror_nocancel
    0x7fffa71e5de4 <+20>: retq
Comment 6 Alex Thurgood 2016-11-24 11:03:05 UTC
(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
Comment 7 Alex Thurgood 2016-11-24 11:11:14 UTC
Created attachment 128988 [details]
bt after commenting out suggested line in scheduler.cxx
Comment 8 Julien Nabet 2016-11-25 19:28:47 UTC
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 ***
Comment 9 Xisco Faulí 2017-10-28 18:23:24 UTC

*** This bug has been marked as a duplicate of bug 103515 ***