Ernest Friedman-Hill wrote:Can we see vts_connect? If we saw the call to strstr, then we could figure out where its arguments came from, and that would let us trace where they might possibly go wrong.
Ernest Friedman-Hill wrote:Indeed. 999,999 times out of a million, your code might work fine -- but it still may not be coded correctly to deal with thread ownership of references or with the possible data movement that can occur due to garbage collection. That's why I said JNI can be tricky.
Rob Prime wrote:
Divya Marwaha wrote:Stack: [0xa2980000,0xa2a00000), sp=0xa29feb58, free space=506k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.1+0x68924] strstr+0x20
C [libjniapi.so+0x1d80] vts_connect+0x134
C [libjniapi.so+0x19e4] __1cQvts_authenticate6F_i_+0x30
C [libjniapi.so+0x1ad4] Java_com_deg_agent_JNILink_vtsCommand+0xc
This is what I see in stack trace. It doesn't appear to be JVM issue.
Looks like the problem is happening in native function call vts_connect(), Is that so???
It appears so. That's indirectly called by class com.deg.agent.JNILink, method String vtsCommand(String). Maybe you're passing a null string and it doesn't check for it.
Ernest Friedman-Hill wrote:Looks like some pretty classic C programming issues. Segvs like these
# C [libc.so.1+0x31fd0] strcpy+0x70
# C [libc.so.1+0x68924] strstr+0x20
are very likely just due to passing dangling pointers around in the native code.
How much do you know about JNI programming? It can be pretty tricky dealing with thread-related memory ownership issues, which I suspect are quite thick in the kind of program you're describing. Maybe you could give us an idea of the scope of your native code, and maybe show us a representative sample.