Description: 1) Start LibreOffice 2) Create a new Firebird embedded database, save the file without having created any tables. 3) In the Tables section, click on "Create Table in design view" 4) Enter a first field name and datatype, eg. "ID", and field type integer. 5) Make the field a required data entry field (NOT NULL) via the UI setting. 6) Before saving the table, try to redimension the table design window, for example, by drawing the mouse from the top left hand corner of the table design window inwards towards the center of the screen. 7) LO hangs, both the main DB window and table design window become non-responsive to mouse or keyboard input, and then LO crashes, leaving a transparent recovery window that remains undrawn (not filled with the recovery dialog content). Steps to Reproduce: See steps described above. Actual Results: Crashes, and leaves an unfilled / unpainted recovery window which eventually disappears, then re-appears. Expected Results: No crash should occur when redimensioning the table design window. Reproducible: Always User Profile Reset: Yes Additional Info: Reproduced with TDF production release 7.3.4.2 and LO master dev build. Version: 7.4.0.0.alpha1+ / LibreOffice Community (x64) Build ID: a353f633ec029fc5c7cdc8062aefb6f979265a9e CPU threads: 8; OS: Mac OS X 12.4; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded and Version: 7.3.4.2 / LibreOffice Community (Arm) Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 8; OS: Mac OS X 12.4; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
Created attachment 180949 [details] Apple stack trace on crashing with LO dev master (x64)
With LO dev master, the crash is instantaneous.
On pc Debian x86-64 with master sources updated today + gen rendering, I don't reproduce this. I suppose it's a Mac only bug or specific Mac with Arm processor. Stephan: do you use a Mac with Arm processor or Intel one? If Intel, do you know whose LO dev we may ping to try to retrieve a bt with symbols?
(In reply to Alex Thurgood from comment #1) > Created attachment 180949 [details] > Apple stack trace on crashing with LO dev master (x64) Apparently the same endless recursion of NSViewGetVisibleRect as in bug 146765. (Which looks slightly familiar, but I can't remember any details. I don't have a Mac around ATM, but can try to remember to look into my old log files next week.)
hi Alex, I'm wondering, does it only happen with a new Firebird embedded database or is it also reproducible with a HSQLDB database ?
This crash looks very much like what is mentioned here: https://www.mikeash.com/pyblog/friday-qa-2014-01-10-lets-break-cocoa.html where a NSView is added to itself. Noting that I cannot reproduce this on my Macbook.
(In reply to Noel Grandin from comment #6) > This crash looks very much like what is mentioned here: > https://www.mikeash.com/pyblog/friday-qa-2014-01-10-lets-break-cocoa.html > where a NSView is added to itself. > It does indeed !
(In reply to Xisco Faulí from comment #5) > hi Alex, > I'm wondering, does it only happen with a new Firebird embedded database or > is it also reproducible with a HSQLDB database ? Hi Xisco, No, it doesn't crash when working with an embedded hsqldb ODB using Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 8b82a71013567e148166b514d0ce0f5905f5a3e3 CPU threads: 8; OS: Mac OS X 12.4; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded However, attempting that same window manipulation with an embedded Firebird ODB brings an immediate crash.
(In reply to Alex Thurgood from comment #8) Also, I still get a hang leading to an eventual crash (after a few minutes of frozen LO windows) with 7.3.4.2 Arm, even when using embedded hsqldb, so it doesn't seem to be just linked to the use of Firebird.
Firebird is experimental at the moment, lowering the importance
(In reply to Stephan Bergmann from comment #4) > Apparently the same endless recursion of NSViewGetVisibleRect as in bug > 146765. (Which looks slightly familiar, but I can't remember any details. > I don't have a Mac around ATM, but can try to remember to look into my old > log files next week.) Sorry, must have misremembered, can't find anything like that in my logs now. (And don't seem to be able to reproduce the issue following the instructions in comment 0, at least with my recent LO master build on macOS on Apple M1.)
Unfortunately, still reproducible on 7412 aarch64 where the office process goes into some kind of ghost display limbo when it crashes, with ghost outlines of the recovery dialog.
I also get an immediate crash with Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: f0a36babf2ef1384666705697f91e7ff4166f4e4 CPU threads: 8; OS: Mac OS X 12.6; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
Created attachment 182602 [details] Apple stack trace on crash with latest master daily dev build 22/09/2022
Created attachment 182603 [details] Screen capture video of how to reproduce I did a video screen capture of how to reproduce the crashing behaviour.
Badfully even with gen rendering with master sources updated today and trying to stick to the screencast, I don't reproduce this (pc Debian x86-64). I'm afraid it's really specific to macOS (or even macOS with specific version + arm) :-(
Still reproducible on Version: 7.5.0.0.beta1 (AARCH64) / LibreOffice Community Build ID: 3aca23eec42e9d6fbe57071d7633ae1fc4bc5fcc CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded Attaching crash dump.
Created attachment 184143 [details] Crash Dump with 7.5 beta aarch64
Suspect that this is a DUP of bug 146765
No longer reproducible with Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: ad387d5b984c6666906505d25685065f710ed55d CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded Setting as DUP of 146765 *** This bug has been marked as a duplicate of bug 146765 ***