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 742070 - Crash on FreeBSD when using "show dependencies"
Crash on FreeBSD when using "show dependencies"
Status: RESOLVED FIXED
Product: system-monitor
Classification: Core
Component: general
3.15.x
Other FreeBSD
: High critical
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
Depends on:
Blocks:
 
 
Reported: 2014-12-28 18:26 UTC by ouzned.alleykatze
Modified: 2015-06-30 20:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ps -aux output (8.76 KB, text/plain)
2014-12-28 19:59 UTC, ouzned.alleykatze
  Details
GDB stacktrace (1.25 KB, text/plain)
2014-12-28 20:00 UTC, ouzned.alleykatze
  Details
Test & fix for pid=0 (2.58 KB, patch)
2014-12-28 21:27 UTC, Benoît Dejean
committed Details | Review
Sanity patches (9.07 KB, patch)
2014-12-28 21:29 UTC, Benoît Dejean
committed Details | Review

Description ouzned.alleykatze 2014-12-28 18:26:40 UTC
On Freebsd, a crash occurs when trying to display the process tree with all the dependencies.

This crash seems to be caused by the FreeBSD kernel process which is identified as PID 0 in the glibtop_server output. This process is then considered to be the parent of all the processes that are not supposed one (ppid = 0).

I have written the following patch that fixes the issue :

https://github.com/Ouzned/gnome-system-monitor/commit/001477f2ceb5049acb0373fb1883dd8c9618d915

Can you have a look at it?
Thanks!
Comment 1 Benoît Dejean 2014-12-28 19:09:09 UTC
Hello Ouzned, could you please provide a stacktrace of your crash ? And maybe a 'ps -ef' ? I'd like to understand it better. Maybe this needs to be fixed at the libgtop level.
Comment 2 ouzned.alleykatze 2014-12-28 19:59:41 UTC
Created attachment 293410 [details]
ps -aux output
Comment 3 ouzned.alleykatze 2014-12-28 20:00:13 UTC
Created attachment 293411 [details]
GDB stacktrace
Comment 4 ouzned.alleykatze 2014-12-28 20:00:33 UTC
Hello Benoît,

Thank you for your quick answer!

Please find attached :

- the core dump
- the ps output (as a normal user)
- the stacktrace as seen in gdb

In the ps output, you'll see the PID 0 "[Kernel]" that causes the crash. As a side note, I also noticed that libgtop doesn't manage to retrieve this process information. The ProcInfo is as good as empty. All the other kernel processes are fine ([geom], [crytpo]...).
Comment 5 ouzned.alleykatze 2014-12-28 20:06:26 UTC
link to core dump : http://dl.free.fr/em7lBumIG
Comment 6 Benoît Dejean 2014-12-28 21:27:54 UTC
Created attachment 293412 [details] [review]
Test & fix for pid=0

I'm running a linux kernel, so I'm injecting a dummy process with pid = 0. This caused the application to crash because the parent node is uninitialized. The root problem is that the current code assumes that no process with pid = 0 can exist. This is obviously wrong now that I know that FreeBSD has "[kernel]" process. On linux, I assumed that all processes have a parent, even if it's 0. This can't work for the "[kernel]" process and using 0 has an undefined value will fail.

So I have changed the type used to store pid from guint to pid_t. We know for sure that pid_t is a signed type because fork(2) can return -1. And from there the problem can be solved.

Here's my test patch.
Comment 7 Benoît Dejean 2014-12-28 21:29:58 UTC
Created attachment 293413 [details] [review]
Sanity patches

I had these not pushed upstreams. It helped me to spot the problem (because ppid == -1 and node was zeroed). I can reduce it if needed, but it might be worthy to apply them all.

Required for my previous patch to work.
Comment 8 Robert Roth 2015-01-03 14:02:47 UTC
Thanks for the patches, I have pushed them to the master after reviewing the code and successfully building and running system monitor issues. Not marking the bug as fixed for the reporter to regress and confirm that the fix works.

Attachment 293412 [details] pushed as 77a8140 - Test & fix for pid=0
Comment 9 Robert Roth 2015-01-03 14:05:17 UTC
Of course, after the reporter confirms that this works, I would like to get rid of the dummy kernel process with 0 pid.
Comment 10 Robert Roth 2015-01-03 14:09:19 UTC
Ok, removed the 0 pid process, as that could've caused strange behaviour in case of a real system having a process with pid 0.

@Ouzned: could you please try  building and running the current master to see if it works correctly now?
Comment 11 Benoît Dejean 2015-01-05 09:29:59 UTC
I think that he sort by PID should actually be a toposort. Let me work on that.
Comment 12 ouzned.alleykatze 2015-01-08 21:23:24 UTC
I've applied both patches and successfully built the application. It seems to work fine, I haven't encountered any crash. 

PID 0 [Kernel] is not never displayed but I don't think that's a problem.

Thanks!
Comment 13 Ting-Wei Lan 2015-02-28 07:35:21 UTC
It doesn't crash now, but PID 0 is displayed without process name.
Comment 14 Benoît Dejean 2015-02-28 08:09:21 UTC
I know, I have the patch in my tree, I'll send it this weekend.
Comment 15 Robert Roth 2015-06-30 20:11:50 UTC
The latest libgtop trunk should correctly set the process name of pid 0 to kernel, crashes have been reported as fixed, so I am setting this as fixed.