I built LO from source today. I reset my user profile. If you search anything in the new search field of the Options dialog, LO will crash. Steps to reproduce: 1) Open any App (in my case it is Writer) 2) Go to Tools - Options 3) Type "Icon" in the search field 4) Do nothing else, just wait a few seconds 5) Crash System info Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 59bf2fbb5f6ebe62b4176c040054ff1c80e2d29a CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL threaded
Confirmed, but just the Options dialog closes without result. No hang and LO continues to run. =-testing-= Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d88779fc86385dde1215fd28b78a69eacc6b4f97 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Created attachment 189457 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I got an assertion only with kf5 rendering (not with gtk3 or gen renderings).
Michael: thought you might be interested in this one since it seems related to accessibility + qt considering the stacktrace. Now I'm afraid there's more than this since V Stuart had problems on Windows.
(In reply to Julien Nabet from comment #3) > Michael: thought you might be interested in this one since it seems related > to accessibility + qt considering the stacktrace. This sounds almost the same as tdf#157092, but is actually a different case (the newly "upgraded" assert from the fix for that one now getting triggered). https://gerrit.libreoffice.org/c/core/+/156782 fixes the crash/assert for Qt-based VCL plugins, s. commit message for details. > Now I'm afraid there's more than this since V Stuart had problems on Windows. That actually seems to be a different thing. (In reply to V Stuart Foote from comment #1) > Confirmed, but just the Options dialog closes without result. > No hang and LO continues to run. > > =-testing-= > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: d88779fc86385dde1215fd28b78a69eacc6b4f97 > CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: threaded This version doesn't contain the fix for tdf#157092 yet. I can't reproduce with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f6a6b1454c7c765c0fc2ef9dc3e6111509a88307 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_DE); UI: en-US Calc: threaded Can you please retest with a newer build? Just to mention it: Waiting for the search to do something instead of pressing Enter (which closes the dialog) in step 4 is essential. I did press Enter at first when trying the feature with qt6, since the search takes a rather long time there and I thought "nothing was happening", so was wondering whether the search had to explicitly triggered there by pressing Enter. In any case, if this is still an issue, I think it should be reported separately.
(In reply to Michael Weghorn from comment #4) > (In reply to Julien Nabet from comment #3) > > Michael: thought you might be interested in this one since it seems related > > to accessibility + qt considering the stacktrace. > > This sounds almost the same as tdf#157092, but is actually a different case > (the newly "upgraded" assert from the fix for that one now getting > triggered). > > https://gerrit.libreoffice.org/c/core/+/156782 fixes the crash/assert for > Qt-based VCL plugins, s. commit message for details. > > > Now I'm afraid there's more than this since V Stuart had problems on Windows. > > That actually seems to be a different thing. > > (In reply to V Stuart Foote from comment #1) > > Confirmed, but just the Options dialog closes without result. > > No hang and LO continues to run. > This version doesn't contain the fix for tdf#157092 yet. I can't reproduce > with > > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: f6a6b1454c7c765c0fc2ef9dc3e6111509a88307 > CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: > win > Locale: en-US (en_DE); UI: en-US > Calc: threaded > > Can you please retest with a newer build? Just retested with the 20230909 daily, same issue of no response and a dialog close with entry--but I was entering "icons". Rather than search for "icons" a search for "icon" or "ico" does respond, and exposes the 'View' panel. So guess I was misusing the search feature. Retest of the 20230901 daily, and it responds the same--"icons" not found and dialog close, but "icon" entry moves to the View panel. Sorry for the noise. =-testing-= 20230909 daily TB77 build Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 65325f9c2f9aff6782fa5df910e8f2f5e63dfd93 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7737dab14baea000810965c572f06a10a94f73df tdf#157160 a11y: Don't assert ValueSetAcc parent on add/remove It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to V Stuart Foote from comment #5) > Just retested with the 20230909 daily, same issue of no response and a > dialog close with entry--but I was entering "icons". > > Rather than search for "icons" a search for "icon" or "ico" does respond, > and exposes the 'View' panel. Thanks for the clarification!
Hi Michael, thanks for fixing this. I've just built from source with your new patch and I confirm that the issue that I reported has been fixed. However, I found another crash. Steps to reproduce: 1) Open Writer 2) In the Options dialog, search for "font" 3) Wait a few seconds until the search ends 4) So far it will work; in the TreeView the "View" entry will be selected 5) Click "Fonts" in the TreeView 6) CRASH Can you confirm this? Is this related? Should I open a new ticket? FTR I tested on a clear user profile. System info Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d6d0bd11ec38978156b9dbbda50bdddc9159e064 CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: threaded
Created attachment 189473 [details] Backtrace of new crash It fails in: 0x00007ffff7833b86 in __assert_fail (assertion=0x7ffff0c3f688 "GetChildCount() == 4 || pWindowImpl->mbInDispose" I've attached the backtrace
(In reply to Rafael Lima from comment #8) > Hi Michael, thanks for fixing this. > > I've just built from source with your new patch and I confirm that the issue > that I reported has been fixed. Thanks for verifying. > However, I found another crash. > > Steps to reproduce: > 1) Open Writer > 2) In the Options dialog, search for "font" > 3) Wait a few seconds until the search ends > 4) So far it will work; in the TreeView the "View" entry will be selected > 5) Click "Fonts" in the TreeView > 6) CRASH > > Can you confirm this? Is this related? Should I open a new ticket? That's an unrelated issue, already reported as bug 157080 and also reproducible one Windows when a screen reader is running. IIRC, commenting out the assert works as a workaround, which also means that release builds are not affected.