Closed dpoetzsch closed 7 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?
Well, without taintgrind valgrind runs fine.
I tested this on a Fedora 24 VM (32-bit). Hope it solves the issue. Sorry it took so long.
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 :-)
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.
Hi,
the last days I've been dealing with always the same error when using taintgrind to analyze my target programs:
I spend quite some time to track it down and actually found multiple ways to reproduce that same error:
Simply by using the
--tainted-ins-only=no
switch even for a super simple input program:Compile and run it with
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.
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: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
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.