Bug 104138

Summary:	CRASH - SIGABRT when attempting to create Firebird3 ODB file - mutex release problem
Product:	LibreOffice	Reporter:	Alex Thurgood <iplaw67>
Component:	Base	Assignee:	Not Assigned <libreoffice-bugs>
Status:	RESOLVED DUPLICATE
Severity:	critical	CC:	serval2412, xiscofauli
Priority:	high	Keywords:	haveBacktrace
Version:	5.3.0.0.alpha1+
Hardware:	x86-64 (AMD64)
OS:	macOS (All)
Whiteboard:
Crash report or crash signature:		Regression By:
Attachments:	backtrace from lldb debugging session bt after commenting out suggested line in scheduler.cxx

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 ***