wmkhoo / taintgrind

A taint-tracking plugin for the Valgrind memory checking tool
GNU General Public License v2.0
247 stars 42 forks source link

[Fedora] Access not within mapped region at address 0x40000000400 #12

Closed dpoetzsch closed 7 years ago

dpoetzsch commented 8 years ago

Hi,

the last days I've been dealing with always the same error when using taintgrind to analyze my target programs:

==7073== Process terminating with default action of signal 11 (SIGSEGV)
==7073==  Access not within mapped region at address 0x40000000400
==7073==    at 0x4016CC7: _dl_runtime_resolve_avx (in /usr/lib64/ld-2.23.so)
==7073==    by 0xFFEFFFD00: ???
==7073==    by 0x4224997: ??? (in /usr/lib64/ld-2.23.so)
==7073==    by 0xFFEFFFD5F: ???
==7073==  If you believe this happened as a result of a stack
==7073==  overflow in your program's main thread (unlikely but
==7073==  possible), you can try to increase the size of the
==7073==  main thread stack using the --main-stacksize= flag.
==7073==  The main thread stack size used in this run was 8388608.

I spend quite some time to track it down and actually found multiple ways to reproduce that same error:

  1. Simply by using the --tainted-ins-only=no switch even for a super simple input program:

    int main() {
       return 0;
    }

    Compile and run it with

    gcc simple.c && valgrind --tool=taintgrind --tainted-ins-only=no ./a.out

    To make the error a bit more difficult to detect, this only happens on my Fedora 24 laptop, not in a lubuntu 14.04 virtual machine.

  2. There seems to be a connection with the file name and working directory and previous working directory. I have an instrumented program that leads to this error in some very specific cases. When I am in the directory /home/cui/gits/master/asb-detection/test/world and run the program the error depends on the length of the file name. If I change directories stuff is different. Finally, even the previous directory seems to be important:

    valgrind --tool=taintgrind --tainted-ins-only=yes ./binary              # No Segfault
    mv binary binary0
    valgrind --tool=taintgrind --tainted-ins-only=yes ./binary0             # Fails with the mentioned error
    valgrind --tool=taintgrind --tainted-ins-only=yes `pwd`/binary0         # No Segfault
    cp binary0 ..
    cd ..
    valgrind --tool=taintgrind --tainted-ins-only=yes ./binary0             # Fails with the mentioned error
    valgrind --tool=taintgrind --tainted-ins-only=yes `pwd`/binary0         # Fails with the mentioned error
    valgrind --tool=taintgrind --tainted-ins-only=yes ./world/binary        # Fails with the mentioned error
    valgrind --tool=taintgrind --tainted-ins-only=yes ./world/binary0       # Fails with the mentioned error
    valgrind --tool=taintgrind --tainted-ins-only=yes `pwd`/world/binary    # No Segfault
    valgrind --tool=taintgrind --tainted-ins-only=yes `pwd`/world/binary0   # No Segfault
    cd ..
    cd test
    valgrind --tool=taintgrind --tainted-ins-only=yes `pwd`/world/binary    # Fails with the mentioned error
    cd world
    cd ..
    valgrind --tool=taintgrind --tainted-ins-only=yes `pwd`/world/binary    # No Segault, again

    This sequence is actually reproducible for me! Again, all of this also only happens on my Fedora 24 laptop, not in the lubuntu 14.04 VM. I tried creating the same directory structure on the lubuntu machine but couldn't make it fail so far.

    By nature of my instrumentation, I only have the instrumented program available in LLVM Bitcode and as binary. I attached both files, maybe they help.

    The bitcode can be easily compiled using

    clang bitcode.ll
    valgrind --tool=taintgrind --tainted-ins-only=yes ./a.out      # No Segfault
    mv a.out aaa.out
    valgrind --tool=taintgrind --tainted-ins-only=yes ./aaa.out    # Fails with the mentioned error

For my project this problem is a real show stopper and I'd be happy to help where I can. I'd also be happy to contribute a patch if needed but at the moment I am really lost on what could be the cause of this issue. Any idea?

PS: I was using the latest github version of taintgrind (c9f8c11811a7b05c2cb57dff4473c881cef9e809).

The files:

tgissue.tar.gz

I also attached a minified version of the bitcode file that still shows the same behavior. Maybe this is worth something.

wmkhoo commented 8 years ago

Hi,

I don't know if this helps or not, but the last time I had a "Access not within mapped region" error, it was a problem with my Makefile. You have no problems running valgrind?

dpoetzsch commented 8 years ago

Well, without taintgrind valgrind runs fine.

wmkhoo commented 7 years ago

I tested this on a Fedora 24 VM (32-bit). Hope it solves the issue. Sorry it took so long.

dpoetzsch commented 7 years ago

Hi, thanks for looking into it. On my Fedora 24 64bit machine the problem persists with valgrind 3.12.0 and taintgrind commit 02ae7cb81d3a16148714b9a2bbe1ea2e29c99ca0:

==22158== 
==22158== Process terminating with default action of signal 11 (SIGSEGV)
==22158==  Access not within mapped region at address 0x40000000400
==22158==    at 0x4016CA7: _dl_runtime_resolve_avx (in /usr/lib64/ld-2.23.so)
==22158==    by 0xFFEFFFDAF: ???
==22158==  If you believe this happened as a result of a stack
==22158==  overflow in your program's main thread (unlikely but
==22158==  possible), you can try to increase the size of the
==22158==  main thread stack using the --main-stacksize= flag.
==22158==  The main thread stack size used in this run was 8388608.
==22158== 
blockSane: fail -- redzone-hi

valgrind: m_mallocfree.c:2101 (vgPlain_arena_free): Assertion 'is_inuse_block(b) && blockSane(a, b)' failed.

host stacktrace:
==22158==    at 0x38078208: show_sched_status_wrk (m_libcassert.c:343)

sched status:
  running_tid=1

I was however able to finish my project using a virtual machine. Thank you for you work :-)

wmkhoo commented 7 years ago

Hi, I wasn't able to reproduce the error using 03bb6de on a 64-bit Fedora 24 VM. I'll close this issue for now.