|
From: Nicholas N. <nj...@cs...> - 2005-10-07 23:48:59
|
Hi, none/tests/execve.c is weird. It just calls execve() on itself. Running under Valgrind with --trace-children=yes I get an endless recursion. Running it normally from the shell I don't get that. Any ideas what is going on? Nick |
|
From: Tom H. <to...@co...> - 2005-10-08 06:41:03
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> none/tests/execve.c is weird. It just calls execve() on itself. Running
> under Valgrind with --trace-children=yes I get an endless recursion.
> Running it normally from the shell I don't get that. Any ideas what is
> going on?
It passes an argument to itself though which is supposed to stop
the recursion.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-10-08 07:00:42
|
Hi, > none/tests/execve.c is weird. It just calls execve() on itself. Running > under Valgrind with --trace-children=yes I get an endless recursion. > Running it normally from the shell I don't get that. Any ideas what is > going on? This is a feature of execve that probably cannot be similated by Valgrind, see coregrind/m_syswrap/syswrap-generic.c from line 2419. The name of the exe actually executed is in ARG1, the name to be shown to the user in ARG2[0]. execve.c passes NULL in ARG2[0], preventing recursion. There seems to be no way to tell Valgrind with --trace-children=yes to do the same. Jeroen. |
|
From: Tom H. <to...@co...> - 2005-10-08 07:06:43
|
In message <4880.194.109.230.85.1128754833.squirrel@194.109.230.85>
"Jeroen N. Witmond" <jn...@xs...> wrote:
> > none/tests/execve.c is weird. It just calls execve() on itself. Running
> > under Valgrind with --trace-children=yes I get an endless recursion.
> > Running it normally from the shell I don't get that. Any ideas what is
> > going on?
>
> This is a feature of execve that probably cannot be similated by Valgrind,
> see coregrind/m_syswrap/syswrap-generic.c from line 2419. The name of the
> exe actually executed is in ARG1, the name to be shown to the user in
> ARG2[0]. execve.c passes NULL in ARG2[0], preventing recursion. There
> seems to be no way to tell Valgrind with --trace-children=yes to do the
> same.
Ah that's right. I new there was something wierd about it. Julian
and I discussed it and decided it wasn't worth trying to make it
work so I think he disabled the test.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-10-08 09:55:29
|
> Ah that's right. I new there was something wierd about it. Julian > and I discussed it and decided it wasn't worth trying to make it > work so I think he disabled the test. We did discuss it and concluded it was too unrepresentative of any real program to be worth catering specially for. But the strange thing is I didn't disable it in the regtest system: sewardj@phoenix:~/VgTRUNK/trunk$ perl tests/vg_regtest none/tests/execve execve: valgrind ./execve == 1 test, 0 stderr failures, 0 stdout failures ================= Maybe its loopfulness depends on which directory it is run from. J |
|
From: Jeroen N. W. <jn...@xs...> - 2005-10-08 11:00:53
|
> >> Ah that's right. I new there was something wierd about it. Julian >> and I discussed it and decided it wasn't worth trying to make it >> work so I think he disabled the test. > > We did discuss it and concluded it was too unrepresentative > of any real program to be worth catering specially for. But the > strange thing is I didn't disable it in the regtest system: > > sewardj@phoenix:~/VgTRUNK/trunk$ perl tests/vg_regtest none/tests/execve > execve: valgrind ./execve > > == 1 test, 0 stderr failures, 0 stdout failures ================= > > Maybe its loopfulness depends on which directory it is run from. > The loopfulness is caused by option --trace-children=yes, which is not used in the regression test. Jeroen. |