Summary: | Valgrind is not looking up $ORIGIN rpath of shebang programs | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Jack Zhao <jack.zhao.fdel> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | tom |
Priority: | NOR | ||
Version: | 3.10.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | repro case |
Description
Jack Zhao
2018-07-11 17:53:02 UTC
I don't think we have any code which does searching for dynamic libraries - we just load the interpreter (ie ld.so) and then let that do the actual dynamic linking. So this must be some environmental difference - either literally in the environment variables, or in the auxilliary vector or something. Hi, thanks for the response. For what it's worth, I was able to reproduce this with a barebones centos7 container. Please see log here: https://pastebin.com/raw/VbvL0khy Steps I took: 1. run a container of the centos:7 official image available from docker.io sudo docker run -i -t centos:7 /bin/bash 2. once in container, install gcc, gcc-c++, and valgrind yum install -y gcc gcc-c++ valgrind 3. download the attached repro case from some available server (or use any method to get the repro case into the container) curl http://<some_server>/test_repro.tar.gz 4. unpack the repro case tar xvzf test_repro.tar.gz 5. cd into the test_repro folder cd test_repro 6. run repro.sh ./repro.sh The test_repro.tar.gz will be attached right after. So if it's an environment-induced problem, it seems to happen in default/typical environments. Any guidance on what kind of environment settings might be causing it? Thanks! Created attachment 113911 [details]
repro case
|