Bug 161815 - StarDesktop.Terminate() will lead to crash if executed by event of a document
Summary: StarDesktop.Terminate() will lead to crash if executed by event of a document
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
24.2.4.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Queries Crash Performance
  Show dependency treegraph
 
Reported: 2024-06-27 14:31 UTC by Robert Großkopf
Modified: 2024-12-24 05:29 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Open the file. Open somthing like task manager also. Write a character … (12.92 KB, application/vnd.oasis.opendocument.text)
2024-06-27 14:31 UTC, Robert Großkopf
Details
Open the database-file. Open the query and close the query. Process for LO wont be shutdown. (4.76 KB, application/vnd.oasis.opendocument.database)
2024-06-27 14:37 UTC, Robert Großkopf
Details
Apple stack trace on hang when closing Query in Base file (3.27 MB, text/plain)
2024-07-02 03:59 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2024-06-27 14:31:48 UTC
Created attachment 195007 [details]
Open the file. Open somthing like task manager also. Write a character …

Open the attached Writer document. Should be the only opened document.
Button is linked to a macro, which saves the document, shows a messagebox and the executes StarDesktop.terminate()
Open a window, which will show the opened processes on your system.
Press the button.
The open process of LibreOffice will be closed.

Macro is also linked to the event "on document change". So set the cursor and write a character.
Same macro runs, same messagebox appears.
On OpenSUSE 15.6 64bit rpm Linux with KDE LO crashes.
Open process of LO will be shown.

This bug appears in different behavior on different platforms. Windows seems to freeze with the frame of Writer.
This bug isn't a special bug of Writer. It also appears in Base if StarDesktop.terminate will be executed by an event of the main database document.
Comment 1 Robert Großkopf 2024-06-27 14:37:09 UTC
Created attachment 195009 [details]
Open the database-file. Open the query and close the query. Process for LO wont be shutdown.

Same behavior with Base. Here the macro is linked to closing of a subdocument. So execute the query and then close this window.
Procedure doesen't contain a messagebox but will do the same:
Saves the file and set StarDektop.terminate.

Version: 24.2.4.2 (X86_64) / LibreOffice Community
Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
Comment 2 Alex Thurgood 2024-07-02 03:44:19 UTC
With the Writer test document provided, and

Version: 24.2.4.2 (AARCH64) / LibreOffice Community
Build ID: b9485aad85c48b4444220279f5499908c52f00f5
CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

I get a crash after typing a letter, and the following error message when the recovery dialog has briefly been displayed:

"LibreOffice must unfortunately be restarted manually after installation or an update."

The error message is misleading at best, and the crash recovery dialog shouldn't really be shown at all, but the soffice process is terminated.
Comment 3 Alex Thurgood 2024-07-02 03:53:48 UTC
With the test Base file, and 

soffice
Path:             /Applications/LO7672.app/Contents/MacOS/soffice
Identifier:       org.libreoffice.script
Version:          7.6.7.2 (7.6.7.2)
Team ID:          7P5S3ZLCN7
Is First Party:   No
Beta Identifier:  6F0F0697-544E-52E6-8449-7384B2E55B50
Architecture:     arm64

I get a hang, requiring a forced kill to exit.

Apple stack trace attached.
Comment 4 Alex Thurgood 2024-07-02 03:58:46 UTC
The problem appears to lie somewhere here in the mutex yield / acquire running on a different thread to the application thread. Race condition ?

CFRunLoopRunSpecific + 608 (CoreFoundation + 508980) [0x187224434]
  56  __CFRunLoopRun + 776 (CoreFoundation + 511380) [0x187224d94]
  56  __CFRunLoopDoObservers + 536 (CoreFoundation + 513896) [0x187225768]
  56  __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 36 (CoreFoundation + 514172) [0x18722587c]
  56  ___NSRunLoopObserverCreateWithHandler_block_invoke + 64 (AppKit + 11674120) [0x18b56c208]
  56  __62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_block_invoke + 272 (AppKit + 1452496) [0x18abac9d0]
  56  CA::Transaction::commit() + 320 (QuartzCore + 11524) [0x18f416d04]
  56  CA::Transaction::run_commit_handlers(CATransactionPhase) + 120 (QuartzCore + 16228) [0x18f417f64]
  56  NSDisplayCycleFlush + 644 (AppKit + 911528) [0x18ab288a8]
  56  NSDisplayCycleObserverInvoke + 168 (AppKit + 912460) [0x18ab28c4c]
  56  __NSWindowGetDisplayCycleObserverForDisplay_block_invoke + 516 (AppKit + 916868) [0x18ab29d84]
  56  -[SalFrameWindow displayIfNeeded] + 88 (libvclplug_osxlo.dylib + 316980) [0x102909634]
  56  SalYieldMutex::doAcquire(unsigned int) + 268 (libvclplug_osxlo.dylib + 139908) [0x1028de284]
  56  std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 28 (libc++.1.dylib + 68372) [0x18706cb14]
Comment 5 Alex Thurgood 2024-07-02 03:59:24 UTC
Created attachment 195077 [details]
Apple stack trace on hang when closing Query in Base file
Comment 6 Patrick (volunteer) 2024-07-08 23:31:41 UTC
(In reply to Alex Thurgood from comment #5)
> Created attachment 195077 [details]
> Apple stack trace on hang when closing Query in Base file

FWIW, LibreOffice 24.2.5 RC1 does not hang on my Silicon Mac nor in my local master build:

Version: 24.2.5.1 (AARCH64) / LibreOffice Community
Build ID: 2ccb78ad6bdfe3f3356a7a7f294ec388775c5816
CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx
Locale: en-CA (en_CA.UTF-8); UI: en-US
Calc: threaded