4 ms·
You might know this, But for those who don't it's very easy to get the stack trace and debug GNOME (or any package) with Arch Linux now due to inclusion of debu
by Abishek_Muthian 4y ago
You might know this, But for those who don't it's very easy to get the stack trace and debug GNOME (or any package) with Arch Linux now due to inclusion of debug packages via Debuginfod service[1] (From which the symbols are automatically downloaded when using gdb).
So for GNOME shell,
coredumpctl gdb /usr/bin/gnome-shell
(gdb) bt full
Then head on to GNOME's gitlab to post the issue, Only to be confronted by similar issues being open for past five years :P
P.S. I mean no offense to GNOME developers and contributors, I love GNOME and use it on all my devices(including phone!) but sometimes I wish they worked more on stability than creating under cooked mechanisms which abuses the system(GNOME extensions).
[1] https://wiki.archlinux.org/title/Debugging/Getting_traces https://wiki.archlinux.org/title/Debugging/Getting_traces
- nyanpasu64 4y agocoredumpctl and gdb aren't very useful at debugging out-of-memory situations. I've had better luck running plasmashell under heaptrack (koute likes to advertise bytehound but it hasn't worked on the programs I tried it on, though I've never reported the bugs). Unfortunately heaptrack usually just indicates that allocations are coming from the QV4 JS engine (since plasmashell, like GNOME Shell, is written substantially in JS), rather than giving me a C++ stack trace. You can try heaptrack on GNOME Shell as well, but you may not have much better luck considering that shell extensions are written in JS (it's possible you'll get a usefully-sized C++ stack trace telling you what resource the JS code is leaking).
- Abishek_Muthian 4y agoThank you for sharing the information, I will be trying heaptrack.