Apport 记录了/usr/bin/gnome-shell我的系统上的一次崩溃。
我可以解压.crash我在中找到的文件/var/crash/，然后使用来查看核心转储gdb，它为我提供：
(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 ()
所以我知道这是一个断言失败。
但是我如何找出哪个断言失败了？因为调用堆栈的信息有限。函数调用没有列出参数，例如
是否可以从这些文件中的任何位置检索断言消息？
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
更新 1
为什么会被否决？这是一个简单的问题……应用程序生成了崩溃报告，但断言失败了。我如何获取断言失败消息？我实在无法理解为什么会有人否决它。
更新 2
正如 Thomas 的评论所暗示的：断言文本确实记录在日志中。运行后journalctl -b -p5得到以下条目：
Apr 24 10:49:21 deca gnome-shell[97980]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
这意味着在当前系统日志中比在崩溃文件中找到原因更容易。
更新 3
好的，现在事情变得非常神秘。我发现我可以让 gdb 从调试服务器下载符号。这样，我就可以看到断言消息的内容。
并且它与系统日志中的不匹配！
断言失败：（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
答案1
唯一可行的方法是 GDB 拥有你正在使用的特定程序的符号。代码中的实际断言失败需要代码符号才能工作，否则你只会得到一个崩溃转储。
但是，您可能能够在 syslog 中找到断言失败数据，而不是使用转储本身。鉴于标准 Ubuntu 22.04gnome-shell默认运行，它也倾向于将数据转储到 syslog。您可以通过 syslog 的输出找到有关断言失败等的详细信息。运行cat /var/log/syslog | grep -i gnome-shell，您可能会找到断言错误数据。
请注意，这并不适用于每个程序 - Bram 在此处讨论的帖子与gnome-shell具体程序相关，并且这种方法适用于gnome-shell。