https://bugs.kde.org/show_bug.cgi?id=481679
Bug ID: 481679
Summary: posix_spawn under valgrind succeeds when it would fail
natively due to a missing executable
Classification: Developer tools
Product: valgrind
Version: 3.22.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: god...@gmail.com
Target Milestone: ---
Created attachment 166013
--> https://bugs.kde.org/attachment.cgi?id=166013&action=edit
posix_spawn_valgrind_test.c test case
SUMMARY
Under valgrind, posix_spawn returns success even though it fails due to a
missing executable name
STEPS TO REPRODUCE
1. Compile the attached program.
2. Run the program natively, observe:
posix_spawn: No such file or directory
3. Run the program under valgrind
OBSERVED RESULT
==85857== Memcheck, a memory error detector
==85857== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==85857== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==85857== Command: ./posix_spawn_valgrind_test
==85857==
==85858==
==85858== HEAP SUMMARY:
==85858== in use at exit: 0 bytes in 0 blocks
==85858== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==85858==
==85858== All heap blocks were freed -- no leaks are possible
==85858==
==85858== For lists of detected and suppressed errors, rerun with: -s
==85858== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
PID of child: 85858
==85857==
==85857== HEAP SUMMARY:
==85857== in use at exit: 0 bytes in 0 blocks
==85857== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==85857==
==85857== All heap blocks were freed -- no leaks are possible
==85857==
==85857== For lists of detected and suppressed errors, rerun with: -s
==85857== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
EXPECTED RESULT
valgrind should properly emulate the call.
SOFTWARE/OS VERSIONS
Ubuntu 22.04 LTS stock
ADDITIONAL INFORMATION
posix_spawn is obviously a tricky function to emulate. Its specification is
also unclear as to what errors are returned and gives the implementation
leeway. For instance, any failure during the exec step may be reported as
initial success, but then the child exiting with 127. On Linux, however, it
uses vfork, and the parent waits until it knows whether the child's exec was
successful or not. This way, it can report a failure during the exec step
directly to the caller rather than reporting success.
Note that (at least in the version I'm looking at), the POSIX_SPAWN_USEVFORK
flag is not used - the implementation always uses `clone()` with CLONE_VFORK
set.
This may be related to https://bugs.kde.org/show_bug.cgi?id=373192
Is there any way to implement the correct semantics here, perhaps with a proper
emulation of vfork?
It would be of tremendous help to people debugging shells under valgrind.
--
You are receiving this mail because:
You are watching all bug changes.
