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 778776 - system-monitor 3.23.90 crashes in Ubuntu
system-monitor 3.23.90 crashes in Ubuntu
Status: RESOLVED FIXED
Product: system-monitor
Classification: Core
Component: general
3.23.x
Other Linux
: Normal critical
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
https://bugs.launchpad.net/ubuntu/+so...
Depends on:
Blocks:
 
 
Reported: 2017-02-16 17:13 UTC by Jeremy Bicha
Modified: 2017-03-27 08:20 UTC
See Also:
GNOME target: ---
GNOME version: 3.23/3.24


Description Jeremy Bicha 2017-02-16 17:13:48 UTC 
gnome-system-monitor 3.23.90-0ubuntu1
Ubuntu 17.04 Alpha

We are still using libgtop2 2.34.2-1. Is that the problem?

gnome-system-monitor crashes when trying to access the Processes tab. Although now it's crashing on startup.

Originally reported at https://launchpad.net/ubuntubugs/1665209

.

+ Trace 237148

Thread 1 (LWP 14185)

  • #0 __GI___libc_free
    at malloc.c line 2963
  • #1 get_process_cgroup_info
    at cgroups.cpp line 114
  • #2 update_info
    at proctable.cpp line 913
  • #3 refresh_list
    at proctable.cpp line 990
  • #4 proctable_update
    at proctable.cpp line 1123
  • #5 update_page_activities
    at interface.cpp line 529
  • #6 create_main_window
    at interface.cpp line 748
  • #7 GsmApplication::on_startup
    at application.cpp line 409
  • #8 Gio::Application_Class::startup_callback
    at application.cc line 930
  • #9 ??
  • #10 ??
  • #11 ??
  • #12 ??
  • #13 ??
  • #14 ??
  • #15 ??
  • #16 ??
  • #17 ?? 






Comment 1


Jeremy Bicha





          2017-02-16 17:14:20 UTC
        






+
Trace
    237149






    

  • 
#0
__GI___libc_free

    
                at malloc.c
                  line
                  2963

    

    • 

  • 
#1
get_process_cgroup_info

    
                at cgroups.cpp
                  line
                  114

    

    • 

  • 
#2
update_info

    
                at proctable.cpp
                  line
                  913

    

    • 

  • 
#3
refresh_list

    
                at proctable.cpp
                  line
                  990

    

    • 

  • 
#4
proctable_update

    
                at proctable.cpp
                  line
                  1123

    

    • 

  • 
#5
update_page_activities

    
                at interface.cpp
                  line
                  529

    

    • 

  • 
#6
create_main_window

    
                at interface.cpp
                  line
                  748

    

    • 

  • 
#7
GsmApplication::on_startup

    
                at application.cpp
                  line
                  409

    

    • 

  • 
#8
Gio::Application_Class::startup_callback

    
                at application.cc
                  line
                  930

    

    • 

  • 
#9
??

    • 

  • 
#10
??

    • 

  • 
#11
??

    • 

  • 
#12
??

    • 

  • 
#13
??

    • 

  • 
#14
??

    • 

  • 
#15
??

    • 

  • 
#16
??

    • 

  • 
#17
??

    • 













Comment 2


Jeremy Bicha





          2017-02-16 17:14:40 UTC
        






+
Trace
    237150






    

  • 
#0
__GI___libc_free

    
                at malloc.c
                  line
                  2963

    

    • 

  • 
#1
get_process_cgroup_info

    
                at cgroups.cpp
                  line
                  114

    

    • 

  • 
#2
update_info

    
                at proctable.cpp
                  line
                  913

    

    • 

  • 
#3
refresh_list

    
                at proctable.cpp
                  line
                  990

    

    • 

  • 
#4
proctable_update

    
                at proctable.cpp
                  line
                  1123

    

    • 

  • 
#5
update_page_activities

    
                at interface.cpp
                  line
                  529

    

    • 

  • 
#6
create_main_window

    
                at interface.cpp
                  line
                  748

    

    • 

  • 
#7
GsmApplication::on_startup

    
                at application.cpp
                  line
                  409

    

    • 

  • 
#8
Gio::Application_Class::startup_callback

    
                at application.cc
                  line
                  930

    

    • 

  • 
#9
??

    • 

  • 
#10
??

    • 

  • 
#11
??

    • 

  • 
#12
??

    • 

  • 
#13
??

    • 

  • 
#14
??

    • 

  • 
#15
??

    • 

  • 
#16
??

    • 

  • 
#17
??

    • 













Comment 3


Robert Roth





          2017-02-16 18:52:40 UTC
        



No, libgtop 2.34.2 should be fine, I doubt that is the reason. Based on the stacktrace it has something to do with cgroups. I will investigate and provide a fix as soon as I can.






Comment 4


Benoît Dejean





          2017-02-16 19:05:58 UTC
        



Jeremy, are you able to run gnome-system-monitor within valgrind ?






Comment 5


Jeremy Bicha





          2017-02-16 19:40:51 UTC
        



(In reply to Benoît Dejean from comment #4)
> Jeremy, are you able to run gnome-system-monitor within valgrind ?

Could you point me to step by step directions of how I should use valgrind?






Comment 6


Benoît Dejean





          2017-02-16 19:43:34 UTC
        



I'm trying Ubuntu alpha right now. The ubuntu button loops forever.
I cannot start any application, even from the file browser, there's no way to start a program. The only way in is alt-f2. <personnal rant/>
Looks like some kind of corruption the lower 32bits are zeroed, but not the upper half.






Comment 7


Jeremy Bicha





          2017-02-16 19:48:31 UTC
        



(In reply to Benoît Dejean from comment #6)
> I'm trying Ubuntu alpha right now. The ubuntu button loops forever.

That's Unity. I think you'd be happier with Ubuntu GNOME.

http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/






Comment 8


Benoît Dejean





          2017-02-16 21:01:54 UTC
        



So,

I've installed that Ubuntu GNOME daily (SO much better)

apt-get build-dep gnome-system-monitor && apt-get source gnome-system-monitor &&  ./configure && make && ./src/gnome-system-monitor

it doesn't segfault at all.

The cgroups are correctly displayed.

Is it possible that something is wrong in the build chain ?






Comment 9


Benoît Dejean





          2017-02-16 21:05:42 UTC
        



But the shipped gnome-system-monitor does segfaults with the same stacktrace.






Comment 10


Robert Roth





          2017-02-16 22:19:38 UTC
        



Adding @Artem Vorotnikov to take a peek, maybe he has an idea.






Comment 11


Benoît Dejean





          2017-02-17 04:24:51 UTC
        



Ubuntu builds with systemd and wnck and -fPIE -fstack-protector-strong.
What I can already tell is that disabling wnck bypasses the problem.
With wnck, the corruption is visible, I can reproduce it even on my debian.






Comment 12


Benoît Dejean





          2017-02-17 06:29:59 UTC
        



I don't think that the corruption even comes from cgroups.cpp.
Making get_process_cgroup_info(info) into a simple logging statement for the value of info.cgroup-name shows a lot of invalid pointers.

Tested with gcc and clang, reproductible in -O0 with -stack-protector-strong.






Comment 13


Benoît Dejean





          2017-02-17 09:24:45 UTC
        



I've bisect the bug, the first bad commit with wnck is the cgroup reform.
https://git.gnome.org/browse/gnome-system-monitor/commit/?id=2c1c564401ad42f24a73a162210bba0e0623fb1f

But it still doesn't make sense.






Comment 14


Benoît Dejean





          2017-02-17 09:42:20 UTC
        



It seems crazy but Artem dropped the #include <config.h>. Adding it back at the top of cgroups.cpp seems to fix this. No more segfault and no more valgrind errors. Robert, can you please test ?






Comment 15


Robert Roth





          2017-02-17 10:44:00 UTC
        



(In reply to Benoît Dejean from comment #14)
> It seems crazy but Artem dropped the #include <config.h>. Adding it back at
> the top of cgroups.cpp seems to fix this. No more segfault and no more
> valgrind errors. Robert, can you please test ?

I have tried adding #include <config.h> to cgroups.cpp, but compiling with --enable-wnck --enable-systemd and -O0 -fstack-protector-strong still gives the sigsegv. As you have also notice, this has something to do with the --enable-wnck option, as with --disable-wnck the app runs fine.






Comment 16


Artem Vorotnikov





          2017-02-17 10:47:57 UTC
        



(In reply to Robert Roth from comment #15)
> (In reply to Benoît Dejean from comment #14)
> > It seems crazy but Artem dropped the #include <config.h>. Adding it back at
> > the top of cgroups.cpp seems to fix this. No more segfault and no more
> > valgrind errors. Robert, can you please test ?
> 
> I have tried adding #include <config.h> to cgroups.cpp, but compiling with
> --enable-wnck --enable-systemd and -O0 -fstack-protector-strong still gives
> the sigsegv. As you have also notice, this has something to do with the
> --enable-wnck option, as with --disable-wnck the app runs fine.

It may be time to re-evaluate the need for WNCK code paths since these seem to be neither tested nor used.






Comment 17


Benoît Dejean





          2017-02-17 23:46:24 UTC
        



I think we are hit by the dual-ABI for std::string.
It would match what I see. I've implemented my own canary and the 4 bytes before string objects are obliterated and I now get segfaults in when ProcInfo construct the first of its string member






Comment 18


Benoît Dejean





          2017-02-18 11:29:57 UTC
        



(In reply to Artem Vorotnikov from comment #16)
> It may be time to re-evaluate the need for WNCK code paths since these seem
> to be neither tested nor used.

I'm still puzzled by the fact that #include <config.h> makes the problem disappear on my system.

Because wnck as always been unstable and because we are also able to get icons from other sources, for the time being and until we understand that heap corruption, we could either disable it or only rename the --enable-wnck to --enable-broken-wnck ?






Comment 19


Artem Vorotnikov





          2017-02-18 12:10:38 UTC
        



(In reply to Benoît Dejean from comment #18)
> 
> Because wnck as always been unstable and because we are also able to get
> icons from other sources, for the time being and until we understand that
> heap corruption, we could either disable it or only rename the --enable-wnck
> to --enable-broken-wnck ?

Also to note is the fact that gtkmm has no bindings for WNCK. Thus if possible, we should cut this code as unportable C.






Comment 20


Benoît Dejean





          2017-02-19 11:35:47 UTC
        



I've pushed a commit to rename the configure option.
https://git.gnome.org/browse/gnome-system-monitor/commit/?id=ffe597e58402b0dfc59bb33ebd92d2ca0dd359de






Comment 21


Jeremy Bicha





          2017-02-19 13:16:19 UTC
        



I rebuilt gnome-system-monitor for Ubuntu without using the --enable-wnck option to get this app working again there.

Debian has been using --enable-wnck for 3 years
https://tracker.debian.org/media/packages/g/gnome-system-monitor/changelog-3.22.2-1






Comment 22


Benoît Dejean





          2017-03-01 12:47:23 UTC
        



I think we could lower the importance of this bug because we have a workaround.






Comment 23


Jeremy Bicha





          2017-03-27 08:20:41 UTC
        



This works now with --enable-wnck with gnome-system-monitor 3.24.0 on Ubuntu, but I've removed that option from the Ubuntu packaging on your recommendation anyway.