GNOME Bugzilla – Bug 742070
Crash on FreeBSD when using "show dependencies"
Last modified: 2015-06-30 20:11:50 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!
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.
Created attachment 293410 [details] ps -aux output
Created attachment 293411 [details] GDB stacktrace
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]...).
link to core dump : http://dl.free.fr/em7lBumIG
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.
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.
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
Of course, after the reporter confirms that this works, I would like to get rid of the dummy kernel process with 0 pid.
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?
I think that he sort by PID should actually be a toposort. Let me work on that.
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!
It doesn't crash now, but PID 0 is displayed without process name.
I know, I have the patch in my tree, I'll send it this weekend.
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.