Perfparser/Hotspot cannot unwind the stack for fork() of created processes #241
Comments
|
Hi Milian, could you please appoint me for fixing this bug. |
|
Hey! Thanks for the report. First of all: what do you mean by "appoint me for fixing this bug" - do you want to look into this issue yourself and submit a patch eventually? I.e. should I assign this issue to you? I'd obviously appreciate that :) But for starters I suggest you create a smaller example that shows this issue which doesn't depend on a larger application like coremark (https://www.eembc.org/coremark/ ?) |
|
Thank you for the response! Yes, you are right. I’ve meant assigning the issue to me. Below is the output of Hotspot for the same perf.data file after my fix. A little bit later I will prepare a small sample. |
|
cool, looking foward to the merge request but since this will most probably target perfparser, could you please consider to push this patch upstream to the qt gerrit perfparser too? |
|
Milian, |
|
maybe start with a merge request for kdab/perfparser and then once that's done upstream it - see https://www.qt.io/contribute-to-qt |
|
I created a merge request for KDAB/perfparser. |
|
Hi, Milian. |
|
I've started on a fix for this issue now and will submit it upstream too. |
A forked process inherits the elfmap of the parent, thus we need to copy that data when we encounter a fork event. To do so reliably, we need to flush the event buffer, as otherwise the mmmap state may not be accurate. Furthermore, pass the ppid through the ThreadStart event, to allow client applications to inherit the comm for the newly created process. Fixes: KDAB/hotspot#241 Change-Id: I5de13644e12def6704c5f622428a815fd87d2af4
|
this issue isn't fully resolved yet, I found a way to reproduce this in a bigger application where the order in which we process events is important - will reopen |
A forked process inherits the elfmap of the parent, thus we need to copy that data when we encounter a fork event. This is complicated by the fact that the task events and mmap events need to be sorted first. Thus, we need to find the fork event when we deplete the buffers after sorting and then initialize the child process elf map with the one from the parent process. Furthermore, pass the ppid through the ThreadStart event, to allow client applications to inherit the comm for the newly created process. Fixes: KDAB/hotspot#241 Change-Id: I5de13644e12def6704c5f622428a815fd87d2af4
A forked process inherits the elfmap of the parent, thus we need to copy that data when we encounter a fork event. This is complicated by the fact that the task events and mmap events need to be sorted first. Thus, we need to find the fork event when we deplete the buffers after sorting and then initialize the child process elf map with the one from the parent process. Furthermore, pass the ppid through the ThreadStart event, to allow client applications to inherit the comm for the newly created process. Fixes: KDAB/hotspot#241 Change-Id: I5de13644e12def6704c5f622428a815fd87d2af4
A forked process inherits the elfmap of the parent, thus we need to copy that data when we encounter a fork event. This is complicated by the fact that the task events and mmap events need to be sorted first. Thus, we need to find the fork event when we deplete the buffers after sorting and then initialize the child process elf map with the one from the parent process. Furthermore, pass the ppid through the ThreadStart event, to allow client applications to inherit the comm for the newly created process. Fixes: KDAB/hotspot#241 Change-Id: I5de13644e12def6704c5f622428a815fd87d2af4
A forked process inherits the elfmap of the parent, thus we need to copy that data when we encounter a fork event. This is complicated by the fact that the task events and mmap events need to be sorted first. Thus, we need to find the fork event when we deplete the buffers after sorting and then initialize the child process elf map with the one from the parent process. Furthermore, pass the ppid through the ThreadStart event, to allow client applications to inherit the comm for the newly created process. Fixes: KDAB/hotspot#241 Change-Id: I5de13644e12def6704c5f622428a815fd87d2af4
A forked process inherits the elfmap of the parent, thus we need to copy that data when we encounter a fork event. This is complicated by the fact that the task events and mmap events need to be sorted first. Thus, we need to find the fork event when we deplete the buffers after sorting and then initialize the child process elf map with the one from the parent process. Furthermore, pass the ppid through the ThreadStart event, to allow client applications to inherit the comm for the newly created process. Fixes: KDAB/hotspot#241 Change-Id: I5de13644e12def6704c5f622428a815fd87d2af4 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The problem was discovered while working with the coremark test.
It concerns multi-threaded mode and USE_FORK model of the test as well as any fork() application.
There is large discrepancy between the values of events costs values for symbols on the Hotspot's Caller/Callee tab and corresponded values of 'perf report'.
The following is 'perf report' output:
And hotspot:
As you can see the events cost are very different not in favor of hotspot.
coremark.exe was built by the command (make XCFLAGS = "- DMULTITHREAD = 4 -DUSE_FORK = 1")
The text was updated successfully, but these errors were encountered: