|
From: Christoph B. <bar...@or...> - 2006-09-25 15:01:21
|
Am Mittwoch, 20. September 2006 23:40 schrieb Josef Weidendorfer: > Regarding this commit: > Christoph, can you check it this is working for you? > Seems to work fine for me. Is the REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x3802779B (???) message each time I use callgrind_control on the child ok? Christoph |
|
From: Josef W. <Jos...@gm...> - 2006-09-25 15:30:08
|
On Monday 25 September 2006 17:01, Christoph Bartoschek wrote: > Am Mittwoch, 20. September 2006 23:40 schrieb Josef Weidendorfer: > > Regarding this commit: > > Christoph, can you check it this is working for you? > > > > Seems to work fine for me. > > Is the > > REDIR: 0xFFFFFFFFFF600000 (???) redirected to 0x3802779B (???) > > message each time I use callgrind_control on the child ok? AFAIK such redirections are decided at translation time of some function. Given that everytime when the instrumentation mode is switched (e.g. by using callgrind_control -i ...) callgrind flushes the translation cache, such a redirection is redone whenever the given function is executed again. So yes, it is reasonable. So the patch seems fine. I still wonder about another thing: After a fork(), usually there is an exec(), which starts callgrind (with --trace-children=yes) again using the same PID. So the callgrind run of the newly started binary probably overwrites profile result files of "same pid before exec()". Ideas how to best solve this? Perhaps Callgrind should add an option for specifing the first sequence number to use for intermediate dumps... Josef |
|
From: Nicholas N. <nj...@cs...> - 2006-09-25 15:50:39
|
On Mon, 25 Sep 2006, Josef Weidendorfer wrote: > I still wonder about another thing: After a fork(), usually there > is an exec(), which starts callgrind (with --trace-children=yes) > again using the same PID. So the callgrind run of the newly started > binary probably overwrites profile result files of "same pid > before exec()". I don't see the problem. The child will have a new PID, the parent will have the old PID, so there shouldn't be any filename collisions. Nick |
|
From: Josef W. <Jos...@gm...> - 2006-09-25 16:06:05
|
On Monday 25 September 2006 17:50, Nicholas Nethercote wrote: > On Mon, 25 Sep 2006, Josef Weidendorfer wrote: > > > I still wonder about another thing: After a fork(), usually there > > is an exec(), which starts callgrind (with --trace-children=yes) > > again using the same PID. So the callgrind run of the newly started > > binary probably overwrites profile result files of "same pid > > before exec()". > > I don't see the problem. The child will have a new PID, the parent will > have the old PID, so there shouldn't be any filename collisions. I thought that exec() only replaces the memory image of a process, but does not create a new one ?! Or does the valgrind launcher fork() itself? Josef |
|
From: Nicholas N. <nj...@cs...> - 2006-09-25 16:14:05
|
On Mon, 25 Sep 2006, Josef Weidendorfer wrote: >>> I still wonder about another thing: After a fork(), usually there >>> is an exec(), which starts callgrind (with --trace-children=yes) >>> again using the same PID. So the callgrind run of the newly started >>> binary probably overwrites profile result files of "same pid >>> before exec()". >> >> I don't see the problem. The child will have a new PID, the parent will >> have the old PID, so there shouldn't be any filename collisions. > > I thought that exec() only replaces the memory image of a process, but > does not create a new one ?! Or does the valgrind launcher fork() itself? The parent (PID 1) forks, creating the child (PID 2). The child immediately exec()s, replacing its memory image with the new program, but keeping the old PID (2). Callgrind should open a new results file when it's started up in the child, no? So I don't see the problem. Please explain in more detail the sequence that you think will cause a problem. Nick |
|
From: Josef W. <Jos...@gm...> - 2006-09-25 16:44:41
|
On Monday 25 September 2006 18:13, Nicholas Nethercote wrote: > The parent (PID 1) forks, creating the child (PID 2). After the fork, the newly created process (PID 2) can be requested to do an intermediate dump, either by callgrind_control (which works now with r6082), or by a client request resulting in a dump file in the namespace of PID 2. As this is the first intermediate dump for this PID, this is "callgrind.out.2.1". > The child immediately > exec()s, replacing its memory image with the new program, but keeping the > old PID (2). Yes. When callgrind is started for the child (PID2), the first intermediate dump with the new executable writes into existing "callgrind.out.2.1" because the dump counter (here the ".1" at end) will have been reset. Perhaps, the user never is interested in what happens between a fork() and a following exec(). When he is, the result could become overwritten. As example: it could be interesting to see what the VG launcher is doing. Or am I missing something here? Josef |
|
From: Nicholas N. <nj...@cs...> - 2006-09-25 16:56:22
|
On Mon, 25 Sep 2006, Josef Weidendorfer wrote: > Perhaps, the user never is interested in what happens between > a fork() and a following exec(). This is what I am assuming -- that the exec() immediately follows the fork(). Nick |