After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 700305 - gnome-system-monitor 3.8.2 crashes on launch
gnome-system-monitor 3.8.2 crashes on launch
Status: RESOLVED FIXED
Product: system-monitor
Classification: Core
Component: general
3.8.x
Other Linux
: Normal major
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
Depends on:
Blocks:
 
 
Reported: 2013-05-14 15:02 UTC by Edward Sheldrake
Modified: 2013-05-14 21:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix crash on launch (3.52 KB, patch)
2013-05-14 15:13 UTC, Edward Sheldrake
none Details | Review

Description Edward Sheldrake 2013-05-14 15:02:37 UTC
gnome-system-monitor 3.8.2 crashes on launch. 3.8.0 didn't. Backtrace:

(gdb) bt full
  • #0 gtk_tree_path_free
    at gtktreemodel.c line 884
  • #1 proctable_update_list
    at proctable.cpp line 1001
  • #2 cb_timeout
    at callbacks.cpp line 466
  • #3 cb_change_current_page
    at callbacks.cpp line 396
  • #4 create_main_window
    at interface.cpp line 433
  • #5 ProcmanApp::on_startup
    at procman-app.cpp line 686
  • #6 Gio::Application_Class::startup_callback
    at application.cc line 613
  • #7 _g_closure_invoke_va
    at gclosure.c line 840
  • #8 g_signal_emit_valist
    at gsignal.c line 3234
  • #9 g_signal_emit
    at gsignal.c line 3384
  • #10 g_application_register
    at gapplication.c line 1318
  • #11 g_application_run
    at gapplication.c line 1577
  • #12 main
    at procman.cpp line 41

Comment 1 Edward Sheldrake 2013-05-14 15:13:15 UTC
Created attachment 244191 [details] [review]
Fix crash on launch
Comment 2 Edward Sheldrake 2013-05-14 15:30:50 UTC
Not fixed enough, rather than crashing on launch it's now crashing after a few seconds, with a similar backtrace:

(gdb) bt full
  • #0 gtk_tree_path_compare
    at gtktreemodel.c line 936
  • #1 proctable_update_list
    at proctable.cpp line 987
  • #2 cb_timeout
    at callbacks.cpp line 466
  • #3 g_timeout_dispatch
    at gmain.c line 4413
  • #4 g_main_dispatch
    at gmain.c line 3054
  • #5 g_main_context_dispatch
    at gmain.c line 3630
  • #6 g_main_context_iterate
    at gmain.c line 3701
  • #7 g_main_context_iteration
    at gmain.c line 3762
  • #8 g_application_run
    at gapplication.c line 1623
  • #9 main
    at procman.cpp line 41

Comment 3 Robert Roth 2013-05-14 17:15:02 UTC
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?
Comment 4 Edward Sheldrake 2013-05-14 18:13:01 UTC
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 ()
Comment 5 Robert Roth 2013-05-14 20:59:53 UTC
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)
Comment 6 Edward Sheldrake 2013-05-14 21:28:36 UTC
Current git HEAD now seems fine, no crashes. Last commit in what I tested was 070c38cf70e48c2a8de45033ec7e8db65018b523.
Comment 7 Robert Roth 2013-05-14 21:43:07 UTC
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.