Bug 271582 - SIGSEV when the tested application execl() applications with LD_PRELOAD
Summary: SIGSEV when the tested application execl() applications with LD_PRELOAD
Status: REPORTED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.6 SVN
Platform: Ubuntu Linux
: NOR crash
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-23 21:27 UTC by kimelto
Modified: 2011-04-30 10:26 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kimelto 2011-04-23 21:27:23 UTC
Version:           3.6 SVN
OS:                Linux

When the application that we want to test with valgrind use the LD_PRELOAD environment variable, valgrind crash when the application call an other process.

Reproducible: Always

Steps to Reproduce:
Write an application which putenv("LD_PRELOAD=whatever.so"); and call an external application with execl() functions. Run this application through valgrind.

Actual Results:  
--7687-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--7687-- si_code=2;  Faulting address: 0x804C0CB;  sp: 0x62ae7c84

valgrind: the 'impossible' happened:
   Killed by fatal signal
==7687==    at 0x38029B9D: mash_colon_env (m_libcproc.c:195)
==7687==    by 0x38029D31: vgPlain_env_remove_valgrind_env_stuff (m_libcproc.c:254)
==7687==    by 0x3807225E: vgSysWrap_generic_sys_execve_before (syswrap-generic.c:2596)
==7687==    by 0x380675E0: vgPlain_client_syscall (syswrap-main.c:1442)
==7687==    by 0x38063927: handle_syscall (scheduler.c:885)
==7687==    by 0x38065402: vgPlain_scheduler (scheduler.c:1081)
==7687==    by 0x38096A34: run_a_thread_NORETURN (syswrap-linux.c:94)

Expected Results:  
A valgrind report.
Comment 1 Stanislav Sedov 2011-04-30 10:26:53 UTC
The same problem happens on FreeBSD as well, and it seems it is cause by valgring trying
to write to the data, referenced by envp, which appears to be write-protected.  It happens
in the mash_colon_env function when it tries to get rid of unwanted env variables.

One of the solutions might be to create a copy of the env string before passing it to
the mash_colon_env function, and reset the env value to a new string if the function
modified it.