O Apport registrou uma falha /usr/bin/gnome-shellno meu sistema.
Posso descompactar o .crasharquivo que encontrei /var/crash/e dar uma olhada no core dump com gdb, que me dá:
(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 ()
Então eu sei que é uma falha de asserção.
Mas como descubro qual afirmação falhou? Porque a pilha de chamadas tem informações limitadas. Não há argumentos listados para as chamadas de função, por exemplo
A mensagem de asserção pode ser recuperada de qualquer lugar nesses arquivos?
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
Atualização 1
Por que os votos negativos? É uma pergunta simples... foi gerado um relatório de travamento de uma aplicação que teve uma falha de asserção. Como posso obter a mensagem de falha de asserção? Não consigo entender por que isso é votado negativamente.
Atualização 2
Conforme sugerido pelo comentário de Thomas: o texto da afirmação foi realmente registrado no diário. A execução journalctl -b -p5produziu esta entrada:
Apr 24 10:49:21 deca gnome-shell[97980]: meta_window_set_stack_position_no_sync: assertion 'window->stack_position >= 0' failed
O que significa que é mais fácil encontrar a causa no log do sistema atual do que no arquivo de travamento.
Atualização 3
Ok, agora fica realmente misterioso. Descobri que posso fazer com que o gdb baixe os símbolos de um servidor de depuração. E com isso, posso ver o conteúdo da mensagem assert.
E não combina com o do syslog!
falha na asserção: (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
A única maneira de isso funcionar seria se o GDB tivesse os símbolos para o programa específico com o qual você está trabalhando. A falha de asserção real no código requer que os símbolos de código funcionem, caso contrário, você simplesmente terá um despejo de memória.
No entanto, você pode encontrar dados de falha de asserção no syslog, em vez de usar o próprio dump. Dado que o Ubuntu 22.04 padrão é executado
gnome-shellpor padrão, ele também tende a despejar dados no syslog. Você pode encontrar detalhes sobre sua falha de asserção, etc. provavelmente pela saída para syslog. Executecat /var/log/syslog | grep -i gnome-shelle você poderá encontrar os dados de erro de asserção.Observe que isso não é garantido para todos os programas - a postagem em questão aqui por Bram está relacionada
gnome-shellespecificamente e essa abordagem funciona paragnome-shell.