GNOME Bugzilla – Bug 700305
gnome-system-monitor 3.8.2 crashes on launch
Last modified: 2013-05-14 21:43:07 UTC
gnome-system-monitor 3.8.2 crashes on launch. 3.8.0 didn't. Backtrace: (gdb) bt full
+ Trace 231940
Created attachment 244191 [details] [review] Fix crash on launch
Not fixed enough, rather than crashing on launch it's now crashing after a few seconds, with a similar backtrace: (gdb) bt full
+ Trace 231941
Strange, it does not crash for me. Anyway, I'll revert the commit causing this, and will investigate it, will try on other computers too. In the meantime, could you check the trunk if it is also crashing?
Yes, trunk is also crashing. The reason it's crashing for me but not you is probably because I've got the environment variable MALLOC_PERTURB_=218 which also explains the 0x2525252525252525 values in the backtraces. See http://udrepper.livejournal.com/11429.html There is also this printed just before the crash: (gnome-system-monitor:2906): Gtk-CRITICAL **: gtk_tree_path_compare: assertion `b != NULL' failed I can fix the crash after startup if I initialize top_of_tree somewhere, e.g.: @@ -358,6 +358,7 @@ ProcmanApp::load_settings() ProcmanApp::ProcmanApp() : Gtk::Application("org.gnome.SystemMonitor", Gio::APPLICATION_HANDLES_COMMAND_LINE) { Glib::set_application_name(_("System Monitor")); + top_of_tree = NULL; } Glib::RefPtr<ProcmanApp> ProcmanApp::get ()
On the stable 3.8 branch I have "fixed" this by reverting the commit and releasing a 3.8.2.1 bugfix release, and I'm working on trunk now. I have checked with MALLOC_PERTURB_=218 environment variable set, system monitor still didn't crash. Anyway, your patch seems OK to me, and it can avoid the warning you have mentioned, as if the tree_path_at_pos returns false, it will not compare the NULL treepath with the other, like it does without the patch, so I have applied it. On top of it, I have added initialization of top_of_tree and other scroll-preserve related variables to proctable creation, could you please try if this does fix the problem for you? (see the HEAD revision)
Current git HEAD now seems fine, no crashes. Last commit in what I tested was 070c38cf70e48c2a8de45033ec7e8db65018b523.
Thanks for the heads-up, the investigation, the quick responses and your help overall. Based on your comment 6 I am marking this as fixed, as this is fixed then both in trunk and in stable.