|
From: Frank L. <fra...@go...> - 2009-11-06 14:55:55
|
Hello list, I guess it's a FAQ/RTMF thing, but I've searched the docs and the web and couldn't find a clue. I'm trying to run callgrind on daemon process that forks childs. The child processes accept network connections, authenticate the remote user and will seteuid ... to some system user. Im calling valgind like this: $ sudo valgrind --tool=callgrind --trace-children=yes <path to binary> ==3473== Callgrind, a call-graph generating cache profiler. ... $ ls -l callgrind.* -rw------- 1 root root 16087 2009-11-06 15:52 callgrind.out.3473 ... remote client logs in... ==3960== Error: can not open cache simulation output file `/home/frank/callgrind.out.3473' I must run valgrind as root, because the binary must be run as root (a fileserver daemon process listening on TCP port 548 (Netatalk)) and the children seteuid ... as described. The main process started under valgrind then writes to to its output file callgrind.out.$PID. The problem is, apparently the forked child tries to write to the same file instead of its own: ==3960== Error: can not open cache simulation output file `/home/frank/callgrind.out.3473' I'm using valgrind 3.3.0. Any hints? Thanks! -Frank |
|
From: Frank L. <fra...@go...> - 2009-11-06 15:30:14
|
2009/11/6 Jeff Johnson <n3...@ma...>: > > On Nov 6, 2009, at 9:55 AM, Frank Lahm wrote: >> >> ==3960== Error: can not open cache simulation output file >> `/home/frank/callgrind.out.3473' >> > > The simplest hack-o-round is to create the file > before invoking callgrind, and ensure that it has > the permissions that the child requires to write the file. > > Use --callgrind-out-file to pass in the file to use. > > Here's is the silly wrapper I use with callgrind because > I can never remember the details: > > hth It might, but as far as I understand you workaround, the child will still write to the same file as the parent?! I can achieve the same easily in my situation, because after I start the main process and before any child forks I can easily chmod/chown the file so that the child can write to it. I've tried that once, and indeed the client wrote its dump there once it exited. But: as soon as I also quit the parent, the parent wrote it's dump to the file, overwriting the stuff from the child. Afaik the processes ought to write to different files, right? Thanks! -Frank |
|
From: Frank L. <fra...@go...> - 2009-11-07 07:39:14
|
2009/11/6 Jeff Johnson <n3...@ma...>: > > On Nov 6, 2009, at 10:30 AM, Frank Lahm wrote: > >> 2009/11/6 Jeff Johnson <n3...@ma...>: >>> >>> On Nov 6, 2009, at 9:55 AM, Frank Lahm wrote: >>>> >>>> ==3960== Error: can not open cache simulation output file >>>> `/home/frank/callgrind.out.3473' >>>> >>> >>> The simplest hack-o-round is to create the file >>> before invoking callgrind, and ensure that it has >>> the permissions that the child requires to write the file. >>> >>> Use --callgrind-out-file to pass in the file to use. >>> >>> Here's is the silly wrapper I use with callgrind because >>> I can never remember the details: >>> >>> hth >> >> It might, but as far as I understand you workaround, the child will >> still write to the same file as the parent?! >> > > Yes. you will need to create the file, and ensure that > the file is writable by the child after root is dropped. > > The script I included shows how to use --callgrind-out-file, nothing more. > >> I can achieve the same easily in my situation, because after I start >> the main process and before any child forks I can easily chmod/chown >> the file so that the child can write to it. > > That will work. > >> I've tried that once, and indeed the client wrote its dump there once >> it exited. But: as soon as I also quit the parent, the parent wrote >> it's dump to the file, overwriting the stuff from the child. >> Afaik the processes ought to write to different files, right? >> > > I can't say when callgrind chooses to dump data. But there are ways > to turn off callgrind at specific points, which should flush at that point. > > Perhaps simplest is add a --debug option to _NOT_ drop root if/when > callgrind > is being used. > > Another approach would be to replace the child executable path with > a wrapper that reinvokes callgrind on the original (but renamed) executable > but specifies a different callgrind file path than the parent's. > > One of those diddle-ups should get you past the problem of dropping root > privs, > yet being able to use callgrind on the parent/child pair. Ok, thanks! With some of that I will get allong. I'm only interested in the dump data of the child, so I don't care if the parents data is foobared. But I still don't understand why the processes dont write to their own file. I mean if the parent had pid 1 and child had pid, shouldn't they dump to callgrind.out.1 and callgrind.out.2 respectively in the first place? A bug? -Frank |
|
From: Josef W. <Jos...@gm...> - 2009-11-09 22:09:25
|
On Saturday 07 November 2009, Frank Lahm wrote: > But I still don't understand why the processes dont write to their own > file. I mean if the parent had pid 1 and child had pid, shouldn't they > dump to callgrind.out.1 and callgrind.out.2 respectively in the first > place? A bug? Yes, this is bug 166581, and it hopefully is fixed in 3.5.0. If you still see problems, please reopen the bug. Josef |