Using ASan with JNA #1147
Comments
|
Hi,
handle_segv=0 is a correct workaround for the first problem - Java needs to
handle its own SEGVs to function.
The second one says that dlsym(RTLD_NEXT, "__cxa_throw") returned nullptr.
Which should never happen AFAIK, because libasan.so is linked to libstdc++.
Try ASAN_OPTIONS=verbosity=2,debug=1 and see if there is anything about
failing to intercept __cxa_throw.
…On Mon, Sep 30, 2019 at 6:35 AM luisfvieirasilva ***@***.***> wrote:
Hi! I have a Java application that calls some native code (C++) through
JNA interface and sometimes the native code breaks. So I'm trying to use
ASan to detect some possible bug inside the native code, but I'm having 2
main problems with this approach.
First problem:
- Description: Right after run JVM ASan inform a SEGV on
address 0x000000000000. I have tried to use option "halt_on_error=0" (using
the option -fsanitize-recover=address during the compilation), but the
program still stopping after SEGV. I imagine that this is caused by JVM,
but don't find a way to fix it.
- Command line: LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.4
ASAN_OPTIONS="" java -Djava.compiler=NONE -jar my-application.jar
- Output:
=================================================================
==27816==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f43294612b4 bp 0x7f433a6fe3e0 sp 0x7f43393e9758 T1)
==27816==The signal is caused by a READ memory access.
==27816==Hint: address points to the zero page.
#0 0x7f43294612b3 (<unknown module>)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (<unknown module>)
Thread T1 created by T0 here:
#0 0x7f433e830d2f in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x37d2f)
#1 0x7f433e5f285b (/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/../lib/amd64/jli/libjli.so+0x885b)
#2 0x7f433e5eea41 (/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/../lib/amd64/jli/libjli.so+0x4a41)
#3 0x7f433e5ef16e in JLI_Launch (/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/../lib/amd64/jli/libjli.so+0x516e)
#4 0x555cf56bf690 (/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java+0x690)
#5 0x7f433e21ab96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
==27816==ABORTING
Second problem:
- Description: A temporary workaround to ignore the first problem is
tell ASan to ignore SEGVs using the option "handle_segv=0". Done that I
have found another problem. JVM (seems to) starts normally, Java code is
executed, call the native code, that seems to execute normally too until it
throws an exception (that has a defined catch) and fail to pass an ASan
check. Looks like the check is during the interception of the throw, but I
don't know why the check fails. Is this means that ASan is reporting an
error inside native code (I suppose not) or ASan itself have broken? A
possible workaround that I have found is compiling asan library without the
option ASAN_HAS_EXCEPTIONS, is this a safe thing to do?
- Command line: LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.4
ASAN_OPTIONS="handle_segv=0" java -Djava.compiler=NONE -jar my-jar.jar
- Output:
==11395==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asan_interceptors.cc:384 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0)
#0 0x7f000eb6cc02 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe9c02)
#1 0x7f000eb8b595 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x108595)
#2 0x7f000eabb26c in __interceptor___cxa_throw (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x3826c)
#3 0x7efb6ef736c9 (/tmp/gbdsNative603198537446672/libgbsce.so+0x3c66c9)
#4 0x7efb6ef71117 (/tmp/gbdsNative603198537446672/libgbsce.so+0x3c4117)
#5 0x7efb6ec8ead4 (/tmp/gbdsNative603198537446672/libgbsce.so+0xe1ad4)
#6 0x7efb6ec87f0f (/tmp/gbdsNative603198537446672/libgbsce.so+0xdaf0f)
#7 0x7efb6ec84d6a (/tmp/gbdsNative603198537446672/libgbsce.so+0xd7d6a)
#8 0x7efb6ec57a7d (/tmp/gbdsNative603198537446672/libgbsce.so+0xaaa7d)
#9 0x7efb8cc3e563 (/tmp/jna--2080775826/jna5669593010908456090.tmp+0x13563)
#10 0x7efb8cc3e2ca (/tmp/jna--2080775826/jna5669593010908456090.tmp+0x132ca)
#11 0x7efb8cc370f4 (/tmp/jna--2080775826/jna5669593010908456090.tmp+0xc0f4)
#12 0x7efb8cc378e0 (/tmp/jna--2080775826/jna5669593010908456090.tmp+0xc8e0)
#13 0x7efff9776bd5 (<unknown module>)
Environment infos:
Distribution: Ubuntu 18.04
Compiler: GCC 7.4.0
Compiler flags: -ggdb -fsanitize=address -fsanitize-recover=address
-fno-omit-frame-pointer -fno-common
I'm not sure if it is a bug or not, but I'm lost about what to do next to
get this working fine and a little help on that would be great.
Thanks for the attention!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1147?email_source=notifications&email_token=AADG4SWD7QRCUPWIQCDQNJ3QMH6DDA5CNFSM4I33AKL2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HORWKYQ>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADG4SUFZQYGM2XZWVDK2J3QMH6DDANCNFSM4I33AKLQ>
.
|
|
Thank you for the response! The first 23 lines of the output: EDIT: I have uploaded the full log on google drive - (https://drive.google.com/open?id=1qDzeXDE86Q3zme_Njbkbw5PjVyCL18L9) |
|
Sorry, I can't reproduce this at all.
Try debugging the failure to intercept __cxa_throw somehow. Try clang
instead of gcc.
…On Mon, Sep 30, 2019 at 12:22 PM luisfvieirasilva ***@***.***> wrote:
Thank you for the response!
I just ran with verbosity and debug option and yes, there is a message
telling that ASan failed to intercept __cxa_throw, is this some bug or I'm
doing something wrong?
The first 23 lines of the output:
==25694==AddressSanitizer: failed to intercept '__isoc99_printf'
==25694==AddressSanitizer: failed to intercept '__isoc99_sprintf'
==25694==AddressSanitizer: failed to intercept '__isoc99_snprintf'
==25694==AddressSanitizer: failed to intercept '__isoc99_fprintf'
==25694==AddressSanitizer: failed to intercept '__isoc99_vprintf'
==25694==AddressSanitizer: failed to intercept '__isoc99_vsprintf'
==25694==AddressSanitizer: failed to intercept '__isoc99_vsnprintf'
==25694==AddressSanitizer: failed to intercept '__isoc99_vfprintf'
==25694==AddressSanitizer: failed to intercept '__cxa_throw'
==25694==AddressSanitizer: libc interceptors initialized
|| `[0x10007fff8000, 0x7fffffffffff]` || HighMem ||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap ||
|| `[0x00007fff8000, 0x00008fff6fff]` || LowShadow ||
|| `[0x000000000000, 0x00007fff7fff]` || LowMem ||
MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff
redzone=16
max_redzone=2048
quarantine_size_mb=256M
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 0x7fff8000
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1147?email_source=notifications&email_token=AADG4SQEW3KWIXDKPEASKZDQMJGWNA5CNFSM4I33AKL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD76ZNEA#issuecomment-536712848>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADG4SVBYNOK7JVCBL6YDUDQMJGWNANCNFSM4I33AKLQ>
.
|
|
It's ok! I have some question about how I can debug the failure to intercept __cxa_throw, could you help me with that?
Thank you very much for the help! |
|
Well there needs to be something exporting __cxa_throw in the library
lookup order after the asan runtime library. Which is basically every other
library, because LD_PRELOAD puts it immediately after the main executable
and before the other libraries AFAIK. Check that there is a libstdc++.so
dependency and that it exports __cxa_throw. Not sure what to do next.
…On Wed, Oct 2, 2019 at 7:24 AM luisfvieirasilva ***@***.***> wrote:
It's ok! I have some question about how I can debug the failure to
intercept __cxa_throw, could you help me with that?
Do you have some intuition about what may cause this failure? I have some
intuitions, but don't know how valid they are...
- Some problem with the compilation, a missing flag or something
similar
- Is there something the native code or the JVM can do during runtime
to cause the failure?
- Can the LD_PRELOAD be involved?
Thank you very much for the help!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1147?email_source=notifications&email_token=AADG4SWK4TVM3TO5SCBMRCTQMSVIRA5CNFSM4I33AKL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAE5YFY#issuecomment-537517079>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADG4SWJNNLP2MJ3YR2W7WTQMSVIRANCNFSM4I33AKLQ>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi! I have a Java application that calls some native code (C++) through JNA interface and sometimes the native code breaks. So I'm trying to use ASan to detect some possible bug inside the native code, but I'm having 2 main problems with this approach.
First problem:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.4 ASAN_OPTIONS="" java -Djava.compiler=NONE -jar my-application.jarSecond problem:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.4 ASAN_OPTIONS="handle_segv=0" java -Djava.compiler=NONE -jar my-jar.jarEnvironment infos:
Distribution: Ubuntu 18.04
Compiler: GCC 7.4.0
Compiler flags: -ggdb -fsanitize=address -fsanitize-recover=address -fno-omit-frame-pointer -fno-common
I'm not sure if it is a bug or not, but I'm lost about what to do next to get this working fine and a little help on that would be great.
Thanks for the attention!
The text was updated successfully, but these errors were encountered: