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 786458 - gnome-system-monitor crashed in "Dependencies" list view
gnome-system-monitor crashed in "Dependencies" list view
Status: RESOLVED OBSOLETE
Product: system-monitor
Classification: Core
Component: process list
3.25.x
Other Linux
: Normal critical
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
Depends on:
Blocks:
 
 
Reported: 2017-08-18 10:12 UTC by Hussam Al-Tayeb
Modified: 2018-05-22 12:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Hussam Al-Tayeb 2017-08-18 10:12:15 UTC 



+
Trace
    237810






Thread 1
          (Thread 0x7f1b5766d940 (LWP 15422))


    

  • 
#0
gtk_tree_model_filter_get_path

    
                at gtktreemodelfilter.c
                  line
                  3124

    

    • 

  • 
#1
gtk_tree_model_filter_row_deleted

    
                at gtktreemodelfilter.c
                  line
                  2679

    

    • 

  • 
#5
<emit signal ??? on instance 0x2dc43f3650 [GtkTreeStore]>

    
                at gsignal.c
                  line
                  3447

    

    • 

  • 
#6
gtk_tree_model_row_deleted

    
                at gtktreemodel.c
                  line
                  1902

    

    • 

  • 
#7
gtk_tree_store_remove

    
                at gtktreestore.c
                  line
                  1230

    

    • 

  • 
#8
remove_info_from_tree<std::__cxx11::list<ProcInfo*> >(GsmApplication*, GtkTreeModel*, ProcInfo&, std::__cxx11::list<ProcInfo*, std::allocator<ProcInfo*> >&, unsigned int)

    
                at proctable.cpp
                  line
                  879

    

    • 

  • 
#9
remove_info_from_tree<std::__cxx11::list<ProcInfo*> >(GsmApplication*, GtkTreeModel*, ProcInfo&, std::__cxx11::list<ProcInfo*, std::allocator<ProcInfo*> >&, unsigned int)

    
                at proctable.cpp
                  line
                  873

    

    • 

  • 
#10
refresh_list

    
                at proctable.cpp
                  line
                  1031

    

    • 

  • 
#11
proctable_update(GsmApplication*)

    
                at proctable.cpp
                  line
                  1142

    

    • 

  • 
#12
cb_timeout(gpointer)

    
                at proctable.cpp
                  line
                  178

    

    • 

  • 
#13
g_timeout_dispatch

    
                at gmain.c
                  line
                  4633

    

    • 

  • 
#14
g_main_dispatch

    
                at gmain.c
                  line
                  3148

    

    • 

  • 
#15
g_main_context_dispatch

    
                at gmain.c
                  line
                  3813

    

    • 

  • 
#16
g_main_context_iterate

    
                at gmain.c
                  line
                  3886

    

    • 

  • 
#17
g_main_context_iteration

    
                at gmain.c
                  line
                  3947

    

    • 

  • 
#18
g_application_run

    
                at gapplication.c
                  line
                  2401

    

    • 

  • 
#19
main(int, char**)

    
                at main.cpp
                  line
                  37

    

    • 













Comment 1


Robert Roth





          2017-08-18 10:24:40 UTC
        



Hi, thanks for reporting this. I can't reproduce this on Fedora 26 with the latest system monitor, the Resources tab with the Dependencies view works normally.

Does this happen all the time, or was it a one-time only issue?






Comment 2


Hussam Al-Tayeb





          2017-08-18 10:28:54 UTC
        



(In reply to Robert Roth from comment #1)
> Hi, thanks for reporting this. I can't reproduce this on Fedora 26 with the
> latest system monitor, the Resources tab with the Dependencies view works
> normally.
> 
> Does this happen all the time, or was it a one-time only issue?

Hello. I definitely have not seen this crash before.






Comment 3


Hussam Al-Tayeb





          2017-08-18 10:32:45 UTC
        



But just to let you know what I was doing, I had sshed from a different computer to this one (using the same user 'hussam') and I was watching the processes started by sshd as user 'hussam'.

After restarting gnome-system-monitor, the crash did not happen again. Eventually I went to the other device and logged off.






Comment 4


Benoît Dejean





          2017-08-18 12:29:56 UTC
        



Unfortunately, that stacktrace is a bit light (we don't even have the signal name). What version are you exactly running ?






Comment 5


Hussam Al-Tayeb





          2017-08-18 12:40:08 UTC
        



3.25.90 revision 8e6d60cd.
In any case, this was the first time I've seen this. But it was also the first time I monitor two concurrent 'hussam' sessions.
It's not urgent.
How can I make the stacktrace better if this ever happen again?
Thank you.






Comment 6


Benoît Dejean





          2017-08-18 16:56:13 UTC
        



What configure arguments have you used ? wnck ?






Comment 7


Hussam Al-Tayeb





          2017-08-18 17:04:34 UTC
        



./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \
    --libexecdir=/usr/lib/ --enable-systemd
I don't have wnck.






Comment 8


Benoît Dejean





          2017-08-18 18:50:35 UTC
        



Ok.

I'm running system-monitor within GDB, with 2 scripts, the 1st one spawing 1000 sort-lived processes, the second one making PID-wraparound happen.

Are you using jhbuild ?
What are your gtk+ version ?






Comment 9


Hussam Al-Tayeb





          2017-08-18 18:56:37 UTC
        



(In reply to Benoît Dejean from comment #8)
> Ok.
> 
> I'm running system-monitor within GDB, with 2 scripts, the 1st one spawing
> 1000 sort-lived processes, the second one making PID-wraparound happen.
> 
> Are you using jhbuild ?
> What are your gtk+ version ?

3.22.18+ revision 170d73e549.

No, I haven't tried jhbuild yet but I'm comfortable enough with creating packages for personal use.






Comment 10


Hussam Al-Tayeb





          2017-08-18 19:30:31 UTC
        



If you wish try to reproduce, try logging into another session from ssh with the same username and run your process test script from there. That should be similar to what I was doing.
What happened was I clicked on the sshd process which was the parent item of the process list of the second 'hussam' session. Then gnome-system-monitor suddenly poofed.






Comment 11


GNOME Infrastructure Team





          2018-05-22 12:19:11 UTC
        



-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-system-monitor/issues/71.