Bug 155624 - A11y crash on cppunittester exit
Summary: A11y crash on cppunittester exit
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.6.0.0 alpha1+
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2023-06-01 12:39 UTC by cwendling
Modified: 2023-07-27 10:58 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Test run log, including backtrace (424.49 KB, text/x-log)
2023-06-01 12:39 UTC, cwendling
Details

Note You need to log in before you can comment on or make changes to this bug.
Description cwendling 2023-06-01 12:39:47 UTC
Created attachment 187640 [details]
Test run log, including backtrace

This is gonna be a weird report as it's involving unavailable code, but here we go anyway:

I'm working on GTK3 a11y tests, which at the moment basically compare every a11y node in LibreOffice against their representation as seen by the platform (AT-SPI).  This already uncovered a couple issues, but anyway, the code should not be doing much of anything worrysome (I can show it, but it's still pretty rough in some places ATM, hence not having a Gerrit patchset online yet), yet I can get it to crash reliably on exit, after a few warnings (see attached test log).

Note that I get this crash only if I let the mainloop run a bit (e.g. using `AccessibilityTools::Wait(5000);` right after loading the document), which leads to several changes in the UI and a11y objects.  Maybe it's related to changes happening then, or how cppunittester abruptly ends the process?

Anyway, I'm not entirely sure how relevant that is for the real use cases of running LO, but it worries me a bit.  So if anybody has an idea on a reason or fix I'd be happy to try it, or provide any code that can be useful for debugging.
Comment 1 Michael Weghorn 2023-07-04 08:46:15 UTC
(In reply to cwendling from comment #0)
> (...) hence not having a Gerrit patchset
> online yet), yet I can get it to crash reliably on exit, after a few
> warnings (see attached test log).

Is that https://gerrit.libreoffice.org/c/core/+/153069 which is online now? If so, can you please elaborate what else to do to make it crash? (if it doesn't do so out of the box, I haven't tried yet)
Comment 2 cwendling 2023-07-04 09:54:57 UTC
(In reply to Michael Weghorn from comment #1)
> Is that https://gerrit.libreoffice.org/c/core/+/153069 which is online now?
> If so, can you please elaborate what else to do to make it crash? (if it
> doesn't do so out of the box, I haven't tried yet)

Yes it is indeed, and no it doesn't crash (at least, shouldn't).

To make it crash as mentioned here, just add a `Scheduler::ProcessEventsToIdle()` in atspi2.cxx's `Test1` (around L446).  You can also uncomment the `dumpA11YTree()` call, as it does run the scheduler (I don't remember why, and it seems weird, I might check why I did that and what happens if it doesn't, but that's another question).
Comment 3 Michael Weghorn 2023-07-26 10:49:42 UTC
(In reply to cwendling from comment #2)
> To make it crash as mentioned here, just add a
> `Scheduler::ProcessEventsToIdle()` in atspi2.cxx's `Test1` (around L446). 
> You can also uncomment the `dumpA11YTree()` call, as it does run the
> scheduler (I don't remember why, and it seems weird, I might check why I did
> that and what happens if it doesn't, but that's another question).

Is that still reproducible for you with a current master?
I tried with PS4 of https://gerrit.libreoffice.org/c/core/+/153069 (to be close to the original state) on top of master as of 6568a29fa256d143a332b424c0582b0e665b65d6 and a revert of be53ee28d7435809e71e7e6b2ce929c87f07ba33 (that would cause another assert otherwise), did the changes you describe and

    make CppunitTest_vcl_gtk3_a11y

runs fine for me.
Comment 4 cwendling 2023-07-27 10:02:41 UTC
Indeed, I'm not able to reproduce this, even with a patch tree from the time of this report (fortunately, I have kept the history locally -- yet I can't be 100% sure if I had everything committed) and on top of ba57377698e7453638233524bc38e6bada5cd7e0.  So either my current clang+dbgutil build does not show this issue, or it has been solved somehow.  Anyway, we can close this as it's at least not usable ATM.
Comment 5 Michael Weghorn 2023-07-27 10:58:37 UTC
OK, let's close this, can still reopen or create a new one if the issue reoccurs somehow in another scenario.