Description of problem: Crashed on startup Version-Release number of selected component: gnome-shell-3.24.2-1.fc26 Additional info: reporter: libreport-2.9.1 backtrace_rating: 4 cmdline: /usr/bin/gnome-shell crash_function: std::_Rb_tree<_ConnectData*, _ConnectData*, std::_Identity<_ConnectData*>, std::less<_ConnectData*>, std::allocator<_ConnectData*> >::equal_range executable: /usr/bin/gnome-shell journald_cursor: s=93e45a7acd3e44f783cf884369ff9dc5;i=2aabf4;b=1d52620f38624daface7db20065cecbf;m=5c2f1e1;t=5522bc74ed1cc;x=6641c1c10271cd6e kernel: 4.11.5-300.fc26.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (5 frames) #0 std::_Rb_tree<_ConnectData*, _ConnectData*, std::_Identity<_ConnectData*>, std::less<_ConnectData*>, std::allocator<_ConnectData*> >::equal_range at /usr/include/c++/7/bits/stl_tree.h:1940 #1 std::_Rb_tree<_ConnectData*, _ConnectData*, std::_Identity<_ConnectData*>, std::less<_ConnectData*>, std::allocator<_ConnectData*> >::erase at /usr/include/c++/7/bits/stl_tree.h:2500 #2 std::set<_ConnectData*, std::less<_ConnectData*>, std::allocator<_ConnectData*> >::erase at /usr/include/c++/7/bits/stl_set.h:675 #3 signal_connection_invalidate_idle at gi/object.cpp:1585 #9 meta_run at core/main.c:648
Created attachment 1288620 [details] File: backtrace
Created attachment 1288621 [details] File: cgroup
Created attachment 1288622 [details] File: core_backtrace
Created attachment 1288623 [details] File: cpuinfo
Created attachment 1288624 [details] File: dso_list
Created attachment 1288625 [details] File: environ
Created attachment 1288626 [details] File: exploitable
Created attachment 1288627 [details] File: limits
Created attachment 1288628 [details] File: maps
Created attachment 1288629 [details] File: open_fds
Created attachment 1288630 [details] File: proc_pid_status
Created attachment 1288631 [details] File: var_log_messages
I've hit this as well after updating gjs from gjs-1.48.3-2.fc26.x86_64 to gjs-1.48.4-1.fc26.x86_64. Downgrading solves the issue for me. I'm would like to propose this as a blocker for F26.
I should also note that was not able to log in to Wayland or X.org session at all, it was crashing all the time.
Proposed as a Blocker for 26-final by Fedora user tpopela using the blocker tracking app because: After updating to gjs-1.48.4-1.fc26.x86_64 (that is in stable) I was not able to log in to GNOME Shell (Wayland session as well as the X.org one) as the gnome-shell was constantly crashing. After downgrading to gjs-1.48.3-2.fc26.x86_64 I was able to log in successfully.
Filed https://bugzilla.gnome.org/show_bug.cgi?id=783951 upstream
I'll investigate this.
Matthew / Tomas: I can't reproduce this with fully updated updates-testing rpm -q gnome-shell mutter gjs gnome-shell-3.24.2-1.fc26.x86_64 mutter-3.24.2-2.fc26.x86_64 gjs-1.48.4-1.fc26.x86_64 Do you have any gnome-shell extensions installed? - it might take very specific circumstances to trigger this.
(In reply to Owen Taylor from comment #18) > Matthew / Tomas: I can't reproduce this with fully updated updates-testing > > rpm -q gnome-shell mutter gjs > gnome-shell-3.24.2-1.fc26.x86_64 > mutter-3.24.2-2.fc26.x86_64 > gjs-1.48.4-1.fc26.x86_64 I do have the same (apart of gjs).. > Do you have any gnome-shell extensions installed? - it might take very > specific circumstances to trigger this. Yes, I do have Alternate Tab and Windownavigator installed and enabled. I will try to disable them and update to newer gjs and let you know.
If you can reproduce this reliably, can you try: https://koji.fedoraproject.org/koji/taskinfo?taskID=20066346 that has a shot-in-the-dark patch for something that might fix this, but I don't feel that confident I've correctly guessed the problem.
Created attachment 1289145 [details] My shot-in-the-dark patch
OK, tried it without any extension enabled and no change in behaviour. Then I tried Owen's scratch buid - GDM crashed immediately. I actually tried gjs-1.48.3-3.fc26.x86_64 by accident (I downloaded a wrong build from koji) and it crashes as well, so whatever was changed between -2 and -3 is causing the issues for me - http://pkgs.fedoraproject.org/cgit/rpms/gjs.git/commit/?id=135600705e932a99464c12dfc0ffebfe9d10f303
Discussed at 2017-06-19 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-19/f26-blocker-review.2017-06-19-16.00.html . We agreed that it's difficult to make a call on this one yet - on the one hand it's clearly affecting more than one person, on the other hand it equally clearly isn't affecting *everyone* and we don't know what the underlying cause is, or have any way to make a reasonable guess as to how broad the impact of the bug will be overall. We'll look at it again next week, hopefully there will be some more information by then.
I don't believe I've reproduced this since posting the bug report. In case it's useful, though: rpm -q gnome-shell mutter gjs gnome-shell-3.24.2-1.fc26.x86_64 mutter-3.24.2-2.fc26.x86_64 gjs-1.48.4-1.fc26.x86_64 Also have openweather (from Fedora) and system monitor (form github) extensions in gnome-shell.
(In reply to Tomas Popela from comment #22) > OK, tried it without any extension enabled and no change in behaviour. Then > I tried Owen's scratch buid - GDM crashed immediately. I actually tried > gjs-1.48.3-3.fc26.x86_64 by accident (I downloaded a wrong build from koji) > and it crashes as well, so whatever was changed between -2 and -3 is causing > the issues for me - > http://pkgs.fedoraproject.org/cgit/rpms/gjs.git/commit/ > ?id=135600705e932a99464c12dfc0ffebfe9d10f303 No surprise, the place that it is crashing is code that was added as a patch in 14.8.3-3: * Tue Jun 13 2017 Bastien Nocera <bnocera> - 1.48.3-3 + gjs-1.48.3-3 - Add fix for possible use-after-free crasher (bgo #781799) What's not so clear is *why* the change is causing a new crash. I'm pretty sure my scratch build doesn't introduce any *additional* crashes, so it's possible that the gdm crash was an upgrade-under-running-system problem, and unrelated. If you can manage to try logging in with my patch just to make sure that it's behaving the same as 1.48.4, that would be appreciate.
> I'm pretty sure my scratch build doesn't introduce any *additional* crashes, > so it's possible that the gdm crash was an upgrade-under-running-system > problem, and unrelated. If you can manage to try logging in with my patch > just to make sure that it's behaving the same as 1.48.4, that would be > appreciate. The GDM was crashing after I restarted the laptop, so definitely not "upgrade-under-running-system problem". In was in some loop, all 3 monitors (2 external + 1 internal) were flashing, I saw the GDM for a second, then it crashed, ...). So as I said it was even worse with your patch.
Can you try if https://koji.fedoraproject.org/koji/taskinfo?taskID=20069412 fixes it? It has Philip's patches from the upstream ticket.
(In reply to Kalev Lember from comment #27) > Can you try if https://koji.fedoraproject.org/koji/taskinfo?taskID=20069412 > fixes it? It has Philip's patches from the upstream ticket. It still crashes, but with different backtrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fc6b0b09f59 in js::GetRuntime (cx=0x5560ca2f9a60) at /usr/include/mozjs-38/jspubtd.h:404 404 return ContextFriendFields::get(cx)->runtime_; Thread 1 (Thread 0x7fc6b2173ac0 (LWP 2793)): #0 0x00007fc6b0b09f59 in js::GetRuntime(JSContext const*) (cx=0x5560ca2f9a60) at /usr/include/mozjs-38/jspubtd.h:404 #1 0x00007fc6b0b09f59 in JS::PersistentRooted<JSObject*>::init(JSContext*, JSObject*) (initial=<optimized out>, cx=0x5560ca2f9a60, this=0x0) at /usr/include/mozjs-38/js/RootingAPI.h:1133 #2 0x00007fc6b0b09f59 in JS::PersistentRooted<JSObject*>::PersistentRooted(JSContext*, JSObject*) (initial=<optimized out>, cx=0x5560ca2f9a60, this=0x0) at /usr/include/mozjs-38/js/RootingAPI.h:1097 #3 0x00007fc6b0b09f59 in __gnu_cxx::new_allocator<JS::PersistentRooted<JSObject*> >::construct<JS::PersistentRooted<JSObject*>, JSContext*&, JS::MutableHandle<JSObject*>&>(JS::PersistentRooted<JSObject*>*, JSContext*&, JS::MutableHandle<JSObject*>&) (this=0x7fc6b0d90520, __p=0x0) at /usr/include/c++/7/ext/new_allocator.h:136 #4 0x00007fc6b0b09f59 in std::allocator_traits<std::allocator<JS::PersistentRooted<JSObject*> > >::construct<JS::PersistentRooted<JSObject*>, JSContext*&, JS::MutableHandle<JSObject*>&>(std::allocator<JS::PersistentRooted<JSObject*> >&, JS::PersistentRooted<JSObject*>*, JSContext*&, JS::MutableHandle<JSObject*>&) (__a=..., __p=0x0) at /usr/include/c++/7/bits/alloc_traits.h:475 #5 0x00007fc6b0b09f59 in std::deque<JS::PersistentRooted<JSObject*>, std::allocator<JS::PersistentRooted<JSObject*> > >::emplace_back<JSContext*&, JS::MutableHandle<JSObject*>&>(JSContext*&, JS::MutableHandle<JSObject*>&) (this=0x7fc6b0d90520) at /usr/include/c++/7/bits/deque.tcc:167 #6 0x00007fc6b0b09f59 in std::stack<JS::PersistentRooted<JSObject*>, std::deque<JS::PersistentRooted<JSObject*>, std::allocator<JS::PersistentRooted<JSObject*> > > >::emplace<JSContext*&, JS::MutableHandle<JSObject*>&>(JSContext*&, JS::MutableHandle<JSObject*>&) (this=0x7fc6b0d90520) at /usr/include/c++/7/bits/stl_stack.h:242 #7 0x00007fc6b0b09f59 in object_instance_init (args=..., object=..., context=<optimized out>) at gi/object.cpp:1451 #8 0x00007fc6b0b09f59 in init_func(JSContext*, unsigned int, JS::Value*) (context=<optimized out>, argc=<optimized out>, vp=0x5560ca2f9a60) at gi/object.cpp:2007 #9 0x00005560c80d34a7 in main (argc=<optimized out>, argv=<optimized out>) at main.c:454 #0 0x00007fc6b0b09f59 in js::GetRuntime(JSContext const*) (cx=0x5560ca2f9a60) at /usr/include/mozjs-38/jspubtd.h:404 gtype = 93874197228912 params = std::vector of length 1456782285678, capacity 1464064405732 = {{ name = 0x1 <error: Cannot access memory at address 0x1>, value = { g_type = 93874194740480, data = {{ v_int = 32, v_uint = 32, v_long = 32, v_ulong = 32, v_int64 = 32, v_uint64 = 32, v_float = 4.48415509e-44, v_double = 1.5810100666919889e-322, v_pointer = 0x20 }, { v_int = 113, v_uint = 113, v_long = 113, v_ulong = 113, v_int64 = 113, v_uint64 = 113, v_float = 1.58346726e-43, v_double = 5.5829417980060859e-322, v_pointer = 0x71 }} } }, { name = 0x0, value = { .... truncated
Discussed at 2017-06-26 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-26/f26-blocker-review.2017-06-26-16.03.html . It still doesn't seem particularly clear how commonly-encountered this one will be; we decided the delay the decision one more time in the hopes more data will show up.
Discussed at 2017-06-29 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-29/f26-blocker-review.2017-06-29-16.00.html . Rejected as a blocker, as it doesn't seem like many people are running into this; we don't have a bunch of dupes, or anything. It seems to be a corner case. This decision can be revisited if more data indicates otherwise.
gjs-1.48.6-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f6910d8598
Please don't close the bug before the update goes stable, Tomas - it's confusing. The standard procedure is the bug goes to MODIFIED when the update is submitted, ON_QA when it's pushed to updates-testing, and CLOSED when the update goes stable. Thanks!
gjs-1.48.6-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f6910d8598
gjs-1.48.6-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.