Summary: | Syscall param execve(envp) contains uninitialised or unaddressable byte(s) | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Peter Seiderer <ps.report> |
Component: | memcheck | Assignee: | Tom Hughes <tom> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | rdykiel |
Priority: | NOR | ||
Version: | 2.1.2 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Patch to avoid banning thread stacks on fork |
Description
Peter Seiderer
2004-07-21 15:38:16 UTC
Both versions of the testprogramm produce no error report when valgrind-2.0.0 is used. It may well be a Valgrind bug; I think Valgrind might crash when execve(foo, NULL, NULL) is executed; strictly speaking I think that's not allowed but the normal execution works ok. In message <20040721141954.12511.qmail@ktown.kde.org> Nicholas Nethercote <njn25@cam.ac.uk> wrote: > It may well be a Valgrind bug; I think Valgrind might crash when > execve(foo, NULL, NULL) is executed; strictly speaking I think that's not > allowed but the normal execution works ok. I think I fixed that didn't I? I think this is something else. Tom Seemingly not, this program segfaults for me: #include <stdlib.h> #include <unistd.h> int main(void) { execve("/bin/true", NULL, NULL); return 0; } I was thinking of bug 83573 which apparently only dealt with envp being a NULL pointer. Is it even legal for argv to be NULL though? Don't you have to at least provide an argv[0] with the program name? I've fixed that execve() problem now but the problem with system when called in a second thread is still occurring. I think the program name goes in the first argument to execve(), and the argv[] array holds the rest. You normally give the program name to execve() twice. The first argument is the name of the program that the kernel will start, but if you want argv[0] to be correct in the started program then you need to provide argv[0] in the call to execve. *** Bug 92763 has been marked as a duplicate of this bug. *** Right. I think I understand what is happening here. The environment is held on the processes initial stack, which is the stack of the main thread. When a process forks valgrind kills all the threads other than the one which does the fork, just as POSIX says it should. Unfortunately when it kills those threads it also marks their stacks as inaccesible. So if you fork in a thread other than the main thread then the main thread's stack (and hence the environment) become inaccessible in the child process. I suspect that the correct fix is not to mark the stacks as inaccesible as they do still exist. That's actually an interesting feature of forking when there are multiple threads - you sort of leak memory because all the other threads are killed bu their stack space is still allocated and accessible. Created attachment 8206 [details]
Patch to avoid banning thread stacks on fork
This patch changes VG_(nuke_all_threads) to disassociate the the stacks of the
threads being killed from the threads rather than marking them as inaccessible.
This should fix the problem with the environment (and other data from the
stacks of other threads) causing warnings after a fork. I believe that
VG_(nuke_all_threads) is only called in places where this is the behaviour that
we want or where it doesn't matter because we're about to exit anyway.
I've now committed my patch to the CVS head but I'd be grateful if you could confirm whether or not it seems to fix the problem for you. Thanks. Thanks for the patch, works for my little test program and the real world application where the error first occured (checked with CVS head). Works for me as well; thanks for the fix. Reopening so I can close with the correct resolution. *** Bug has been marked as fixed ***. |