|
From: Wayne B. <wbo...@gm...> - 2013-04-21 15:20:47
|
A valgrind log snip after adding
--trace-syscalls=yes -v -v -v -d -d -d
Can be seen at: http://pastebin.com/wZb2vbye
(had to use pastebin, since this list will not accept anything more than 40k)
>From what I can tell, it looks like the process is started, but nothing
happens after that?
On Sun, Apr 21, 2013 at 11:34 AM, Wayne Booth
<wbo...@gm...>wrote:
> Hi all,
>
> I have a program (it forks itself to become a daemon, then starts a number
> of worker threads) which can start a sub-process (from 'only one of the
> threads at a time') by calling fork followed by execvp.
>
> When I run the program directly, the program works as expected and the
> sub-process is called, runs, logs and returns well.
>
> When the program is started under valgrind, the sub-process seams not to
> run - it does not log or return anything (via its pipe) and valgrind does
> not report anything about that process. execvp does not return, so
> something is starting, but I can't work out what. Any idea what I may be
> doing wrong?
>
> This is the command I'm using to start the process/valgrind:
> valgrind --leak-check=full --leak-resolution=high --error-limit=no
> --tool=memcheck --num-callers=50
> --log-file=results/resultsFiles/valgrind.out --show-below-main=yes
> --track-origins=yes --track-fds=yes --show-reachable=yes
> --trace-children=yes /tmp/opendias_test/bin/opendias >
> results/resultsFiles/appLog.out
>
> I can post the sub-process calling (pipe, fork, execvp) code if that helps.
>
> Cheers for any help.
>
> Wayne Booth
>
|
|
From: Wayne B. <wbo...@gm...> - 2013-04-21 21:21:44
|
Hi, Thanks for your feedback. I've done a run under strace: wbooth@netbook:~/git/clearscene-src-opendias/test$ strace -f -o /tmp/strace.out valgrind --trace-syscalls=yes --leak-check=full --leak-resolution=high --error-limit=no --tool=memcheck --num-callers=50 --log-file=results/resultsFiles/valgrind.out --show-below-main=yes --track-origins=yes --track-fds=yes --show-reachable=yes --trace-children=yes /tmp/opendias_test/bin/opendias And the relevant snip from the strace.out log is here: http://pastebin.com/gzfamVSX As you can see (from above), the process is started in: /home/wbooth/git/clearscene-src-opendias/test and valgrind is asked to write a log at: results/resultsFiles/valgrind.out This is fine for the main process. However, shortly after the original fork (to become a daemon) the main process changes the working directory to "/tmp". As you can see from the strace log, valgrind tries to write to a non existent log file "/tmp/results/resultsFiles/valgrind.out", cannot, so finishes up with a "exit_group(1)", which would account for all the symptoms we've seen. I've updated my tests to call valgrind referencing suppression and log files will full paths, and everything is working as expected. Thanks for your help is resolving this blocker. I don't think that valgrind is doing anything wrong here, so all good. Regards Wayne |
|
From: John R. <jr...@bi...> - 2013-04-21 17:52:14
|
On 04/21/2013 08:20 AM, Wayne Booth wrote: > A valgrind log snip after adding > > --trace-syscalls=yes -v -v -v -d -d -d > > Can be seen at: http://pastebin.com/wZb2vbye > From what I can tell, it looks like the process is started, but nothing happens after that? Apparently so; after SYSCALL[7582,2]( 11) sys_execve ( 0x806a594(/tmp/opendias_test/bin/opendias_worker), 0x72b2eb0, 0xbeb9c10c )SYSCALL[7580,2](162) ... [async] --> Success(0x0:0x0) there are no "SYSCALL[7582,". But was that because: 1) valgrind printed the pre-syscall message for execve, but never actually performed the syscall? 2) valgrind did perform the execve, but the system did not run process 7582 after the execve? 3) valgrind did not run process 7582 after the execve? Therefore we need an independent observer, namely strace. [On a side note, the protocol involving file descriptor 7 after the fork() and before the execve() was hard to follow. Is everything OK there?] -- |