Bug 142549 - Assertion failure when closing LO
Summary: Assertion failure when closing LO
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
7.2.0.0 alpha1+
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.2.0
Keywords:
Depends on:
Blocks: GTK3 Crash-Assert
  Show dependency treegraph
 
Reported: 2021-05-28 21:38 UTC by Aron Budea
Modified: 2021-05-30 19:05 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
bt when inserting in list (7.08 KB, text/plain)
2021-05-29 13:31 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2021-05-28 21:38:14 UTC
In a debug build, start one of the apps, eg. Writer or Calc, then quit LO.

=> Assertion failure.

vcl/unx/gtk3/a11y/atkutil.cxx:437: {anonymous}::WindowList::~WindowList(): Assertion `list.empty()' failed.

Observed in a debug build of LO 7.2.0.0.alpha1+ (75b6b7f66b6ff66f8d9945bccdef71952db2d966) / Ubuntu.

Caolán, perhaps you have an idea why this might happen.
Comment 1 Julien Nabet 2021-05-29 13:21:58 UTC
On pc Debian x86-64 with master sources updated today + gtk3 I could reproduce this.
bt isn't very interesting, the only relevant point has been already indicated by Aron.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f84b8cfa537 in __GI_abort () at abort.c:79
#2  0x00007f84b8cfa40f in __assert_fail_base
    (fmt=0x7f84b8e63128 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f84a58d0b26 "list.empty()", file=0x7f84a58d0b33 "/home/julien/lo/libreoffice/vcl/unx/gtk3/a11y/atkutil.cxx", line=437, function=<optimized out>) at assert.c:92
#3  0x00007f84b8d09662 in __GI___assert_fail
    (assertion=0x7f84a58d0b26 "list.empty()", file=0x7f84a58d0b33 "/home/julien/lo/libreoffice/vcl/unx/gtk3/a11y/atkutil.cxx", line=437, function=0x7f84a58d0b6d "(anonymous namespace)::WindowList::~WindowList()") at assert.c:101
#4  0x00007f84a55b0767 in (anonymous namespace)::WindowList::~WindowList() (this=0x7f84a5ae8248 <(anonymous namespace)::g_aWindowList>) at vcl/unx/gtk3/a11y/atkutil.cxx:437
#5  0x00007f84b8d134d7 in __run_exit_handlers (status=0, listp=0x7f84b8e93718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#6  0x00007f84b8d1367a in __GI_exit (status=<optimized out>) at exit.c:139
#7  0x00007f84b8cfbd11 in __libc_start_main (main=0x400840 <main>, argc=3, argv=0x7ffcc0d9a018, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcc0d9a008)
    at ../csu/libc-start.c:342
#8  0x000000000040073a in _start ()
Comment 2 Julien Nabet 2021-05-29 13:31:19 UTC
Created attachment 172434 [details]
bt when inserting in list
Comment 3 Caolán McNamara 2021-05-29 19:02:22 UTC
I feel this must be a very recent problem seeing as we typically start and exit a dbgutil version of LibreOffice frequently
Comment 4 Caolán McNamara 2021-05-29 19:51:15 UTC
gtk a11y assert on exit bisects to

commit d90aa314961ea4a6893144cd6be66dd71cc2cca1 (refs/bisect/bad)
Date:   Fri May 28 20:39:00 2021 +0200

    IsDisposed->isDisposed in vcl/../app
Comment 5 Caolán McNamara 2021-05-29 20:02:23 UTC
https://gerrit.libreoffice.org/c/core/+/116396 to revert the bit that's causing the problem
Comment 6 Commit Notification 2021-05-30 14:05:40 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f781691a6e35923acf64e11e082c4173fcf9d5e6

tdf#142549 Assertion failure when closing LO in gtk a11y

It will be available in 7.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.
Comment 7 Aron Budea 2021-05-30 15:15:32 UTC
I'm assuming the random bug in See also has no relation to this one.
Comment 8 Julien Nabet 2021-05-30 19:05:56 UTC
With master sources updated today, I don't reproduce the assertion.
Thank you Caolán!