Join Log in
Score:-1
Bram avatar Ubuntu

Retrieve an assertion failure from a .crash file

cn flag
Bram

Apport has recorded a crash of /usr/bin/gnome-shell on my system.

I can unpack the .crash file that I found in /var/crash/ and I can take a look at the core dump with gdb, which gives me:

(gdb) where
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007f60a3a3c406 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
#4  0x0000555b78a65aea in  ()
#5  0x00007f60a3a3c4b0 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
#6  __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#7  __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#8  __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#9  0x00007f60a3a3c406 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#10 0x00007f60a3a2287c in __GI_abort () at ./stdlib/abort.c:79
#11 0x00007f60a4306d1e in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007f60a436e22e in g_assertion_message_expr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007f60a3ed9336 in  () at /lib/x86_64-linux-gnu/libmutter-12.so.0
#14 0x00007f60a3efcc8c in  () at /lib/x86_64-linux-gnu/libmutter-12.so.0
#15 0x00007f60a3effdcd in  () at /lib/x86_64-linux-gnu/libmutter-12.so.0
#16 0x00007f60a434236f in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007f60a439d178 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007f60a4341bdf in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007f60a3ebde19 in meta_context_run_main_loop () at /lib/x86_64-linux-gnu/libmutter-12.so.0
#20 0x0000555b78a64fa1 in  ()
#21 0x00007f60a3a23a90 in __libc_start_call_main (main=main@entry=0x555b78a64b10, argc=argc@entry=1, argv=argv@entry=0x7fff6a9da2c8)
    at ../sysdeps/nptl/libc_start_call_main.h:58
#22 0x00007f60a3a23b49 in __libc_start_main_impl
    (main=0x555b78a64b10, argc=1, argv=0x7fff6a9da2c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff6a9da2b8) at ../csu/libc-start.c:360
#23 0x0000555b78a65275 in  ()

So I know it is an assertion failure.

But how do I find out which assertion failed? Because the callstack has limited information. There are no arguments listed for the function calls, e.g.

Is the assertion message retrievable from anywhere in these files?

ApportVersion         Disassembly          InstallationMedia    ProcCpuinfoMinimal      separator                   ThreadStacktrace
Architecture          DisplayManager       JournalErrors        ProcCwd                 ShellJournal                Title
CasperMD5CheckResult  DistroRelease        _MarkForUpload       ProcEnviron             Signal                      Uname
CoreDump              ExecutablePath       monitors.xml         ProcMaps                SourcePackage               UpgradeStatus
CrashCounter          ExecutableTimestamp  Package              ProcStatus              Stacktrace                  UserGroups
CurrentDesktop        GsettingsChanges     PackageArchitecture  ProcVersionSignature    StacktraceAddressSignature
Date                  _HooksRun            ProblemType          Registers               StacktraceTop
Dependencies          InstallationDate     ProcCmdline          RelatedPackageVersions  Tags

Update 1

Why the downvotes? It is a simple question... a crash report was generated of an application that had an assertion fail. How can I get the assertion failure message? I can't for the life of me understand why this is downvoted.

Update 2

As suggested by Thomas' comment: the assertion text was indeed logged in the journal. Running journalctl -b -p5 yielded this entry:

Apr 24 10:49:21 deca gnome-shell[97980]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed

Which means it is easier to find the cause in the current system log, than in the crash file.

Update 3

Ok, now it gets really mysterious. I found that I can have gdb download the symbols from a debugserver. And with that, I can see the contents of the assert message.

And it mismatches the one in the syslog!

assertion failed: (window->display->focus_window != window)

(gdb) where
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007f60a3a3c406 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x0000555b78a65aea in dump_gjs_stack_on_signal_handler (signo=6) at ../src/main.c:495
#5  0x00007f60a3a3c4b0 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
#6  __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#7  __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#8  __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#9  0x00007f60a3a3c406 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#10 0x00007f60a3a2287c in __GI_abort () at ./stdlib/abort.c:79
#11 0x00007f60a4306d1e in g_assertion_message
    (domain=domain@entry=0x7f60a3f87752 "libmutter", file=file@entry=0x7f60a3f9eb09 "../src/core/window.c", line=line@entry=1533, func=func@entry=0x7f60a3fa10d0 <__func__.53> "meta_window_unmanage", message=message@entry=0x555b7c8a2950 "assertion failed: (window->display->focus_window != window)") at ../../../glib/gtestutils.c:3450
#12 0x00007f60a436e22e in g_assertion_message_expr
    (domain=domain@entry=0x7f60a3f87752 "libmutter", file=file@entry=0x7f60a3f9eb09 "../src/core/window.c", line=line@entry=1533, func=func@entry=0x7f60a3fa10d0 <__func__.53> "meta_window_unmanage", expr=expr@entry=0x7f60a3fa0960 "window->display->focus_window != window") at ../../../glib/gtestutils.c:3476
#13 0x00007f60a3ed9336 in meta_window_unmanage (window=0x555b80df26b0, timestamp=<optimized out>) at ../src/core/window.c:1533
#14 0x00007f60a3efcc8c in meta_x11_display_handle_xevent (event=<optimized out>, x11_display=<optimized out>) at ../src/x11/events.c:1981
#15 xevent_func (xevent=0x7fff6a9d9ee0, data=0x555b7c1fdce0) at ../src/x11/events.c:2021
#16 0x00007f60a3effdcd in meta_x11_event_source_dispatch (source=0x555b7f14b0c0, callback=0x7f60a3efc410 <xevent_func>, user_data=0x555b7c1fdce0) at ../src/x11/meta-x11-event-source.c:64
#17 0x00007f60a434236f in g_main_dispatch (context=0x555b791a83b0) at ../../../glib/gmain.c:3460
#18 g_main_context_dispatch (context=0x555b791a83b0) at ../../../glib/gmain.c:4200
#19 0x00007f60a439d178 in g_main_context_iterate.constprop.0 (context=0x555b791a83b0, block=<optimized out>, dispatch=1, self=<optimized out>) at ../../../glib/gmain.c:4276
#20 0x00007f60a4341bdf in g_main_loop_run (loop=0x555b7b53a060) at ../../../glib/gmain.c:4479
#21 0x00007f60a3ebde19 in meta_context_run_main_loop (context=context@entry=0x555b791a6780, error=error@entry=0x7fff6a9da128) at ../src/core/meta-context.c:482
#22 0x0000555b78a64fa1 in main (argc=<optimized out>, argv=<optimized out>) at ../src/main.c:765
156
1 + 3
ru flag
Thomas Ward
The only way this would work is if GDB had the symbols for the specific program you're working with. The actual assertion failure in code requires the code symbols to work, otherwise you simply have a crash dump. However, you might be able to find assertion failure data in syslog, rather than using the dump itself. Run `cat /var/log/syslog | grep -i gnome-shell` and include the output in your post as an edit. The assertion failure in the Dump is not going to be as helpful as the probable output in syslog by gnome-shell prior to the crash.
1
Reply
Bram avatar
cn flag
Bram
@ThomasWard Excellent suggestion! The assertion was indeed listed in the syslog. If you write it up as an answer, I will mark it as the solution. I expected the assertion text to be included in the .crash report, but you can simply find it in the system logs.
0
Reply
ru flag
Thomas Ward
I know for a fact that only works with `gnome-shell` I can't guarantee it as others. So I'll write the answer specifically for `gnome-shell`
0
Reply
Score:2
avatar Ubuntu
ru flag
Thomas Ward

The only way this would work is if GDB had the symbols for the specific program you're working with. The actual assertion failure in code requires the code symbols to work, otherwise you simply have a crash dump.

However, you might be able to find assertion failure data in syslog, rather than using the dump itself. Given that standard Ubuntu 22.04 runs gnome-shell by default, it tends to dump data to syslog too. You can find details on your assertion failure, etc. probably by the output to syslog. Run cat /var/log/syslog | grep -i gnome-shell and you might find the assertion error data.

Note this is not guaranteed for every program - the post in question here by Bram is related to gnome-shell specifically and this approach works for gnome-shell.

+ 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.