主页 / ubuntu / 问题 / 1464925
Accepted
Bram
Asked: 2023-04-24 08:21:03 +0800 CST

从 .crash 文件中检索断言失败

  • 772

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
crash

1 个回答

  1. Best Answer

    唯一可行的方法是 GDB 具有您正在使用的特定程序的符号。代码中的实际断言失败需要代码符号才能工作，否则您只会得到一个故障转储。

    但是，您可能能够在 syslog 中找到断言失败数据，而不是使用转储本身。鉴于标准的 Ubuntu 22.04gnome-shell默认运行，它也倾向于将数据转储到系统日志。您可以通过系统日志的输出找到有关断言失败等的详细信息。运行cat /var/log/syslog | grep -i gnome-shell，您可能会发现断言错误数据。

    请注意，这并不能保证每个程序都适用 - Bram 在这里发表的有问题的帖子专门与此相关gnome-shell，并且这种方法适用于gnome-shell.

    • 2

相关问题