GNOME Bugzilla – Bug 783771
gnome-shell crash after playing Flash video in Firefox or Chrome
Last modified: 2017-11-10 07:36:52 UTC
From bug 781799. Report 1 (no backtrace): > Applied two patches yesterday and today when watching youtube in Chrome. > gnome-shell[461]: segfault at 7fac98dfffe8 ip 00007faccdde2cad sp 00007ffe1f01ba70 error 4 in libgjs.so.0.0.0[7faccddb3000+c8000] Report 2 (backtrace with symbols in attachment 353710 [details]): > I did experience another crash after applying the above two patches, when closing a Firefox window playing a flash video (cnn.com) Looks like a function is being called in the wrong compartment. Information that would be useful: - Instructions for reproducing reliably - Output of `call gjs_dumpstack()` in GDB
I attached gdb to gnome shell from a VT, and then was able to reproduce the crash. However, it looks like with Wayland gnome-shell hung, I am not able to switch back to the VT to investigate. I guess I'll need to reproduce under X11, or is there a better way to debug this crash?
To work with gdb immediately at the crash point (run gnome-shell inside it), you probably would need to run gdb on that machine via ssh from another machine. I believe you will have the same problem with X11 as well when gdb trap hits. Alternatively maybe you don't need to do it live, but just get a core dump saved instead, and then give gdb the core dump to process together with the executable. If you use systemd, then that might already have it saved in coredumpctl, take a look then. coredumpctl gdb gnome-shell or some such (it might open a different crash of gnome-shell than you intended without some specifying) might just do that "open gdb with the core dump" part for you, then "threads apply all bt full" or so from there. But I'm not sure if the `call gjs_dumpstack()` part of it will work this way or not when loaded from coredump. Without systemd might just want to do "ulimit -c unlimited" on the tty you launch gnome-shell from, then it should dump the core file to your CWD of the tty, I believe.
Thanks! I do have the coredumps stored by coredumpctl - that's where the attached `bt full` came from -- but I think I need a running instance of gnome-shell in order to invoke `gjs_dumpstack` -- gdb says: > You can't do that without a process to debug. So I assumed I needed a live, attached process. I can try later to debug over SSH when I have access to my desktop.
Yes, `call gjs_dumpstack()` would be extremely helpful. I am fairly certain about what needs to be patched, but not why, so understanding what is going on is key.
John, did you get a chance to debug over SSH and/or post some reproducer instructions?
(In reply to John from comment #1) > I attached gdb to gnome shell from a VT, and then was able to reproduce the > crash. However, it looks like with Wayland gnome-shell hung, I am not able > to switch back to the VT to investigate. I guess I'll need to reproduce > under X11, or is there a better way to debug this crash? I used a following command in third terminal for debugging of gnome-shell crash. SSH is too complex for me. (bash) sleep 5m; chvt 2;
(In reply to Philip Chimento from comment #5) > John, did you get a chance to debug over SSH and/or post some reproducer > instructions? I spent some time this afternoon trying to reproduce while gdb was attached over SSH. Unfortunately (?) I wasn't able to trigger the crash. It seems to not occur every time. Sorry -- I'll keep trying and post back if I can trigger it on demand.
Closing this bug report as no further information has been provided; I'm trying to clean things up in preparation for migration to GitLab. Please feel free to reopen this bug report on GitLab if you can provide the information that was asked for in a previous comment. Thanks!