SIGSEGV (SEGV_ACCERR) Crash When Linking to a Custom Library

[Phillip Weisberg]

Hello,

I am running into a native crash using the Android 2.3.3 (API level
10) emulator. I have linked my Android application against my custom
native library "libcore.so" and verified that the .apk file contains
the library. When my application is linked to this library (even if I
do not call any functions in the library), the application will crash
due to a SIGSEGV (SEGV_ACCERR) signal.

The reason that a SEGV_ACCERR signal is generated is because of
"invalid permissions for mapped object" (http://en.wikipedia.org/wiki/
SIGSEGV). Is it possible that this could be caused by static data
members being instantiated or used improperly? Alternatively, are
there any standard pitfalls to be aware of regarding generating native
libraries for Android?

The output of the Android tombstone can be found below for reference.
There are a few lines in the call stack referring to the heap which
makes me think that the issue may stem from run-time instantiation of
objects in libcore.so. Unfortunately, using "addr2line" did not
provide any information about the function in which the crash is
occurring.

If anyone has a suggestion on how to go about debugging this issue, it
would be greatly appreciated.

Cheers,
Phillip



*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'generic/sdk/generic:2.3.3/GRI34/101070:eng/test-
keys'
pid: 340, tid: 340 >>> com.example.CoreTest <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 80017f40
r0 fffffffc r1 8054e0f0 r2 00001000 r3 bebfdffc
r4 bebfe024 r5 00000009 r6 00000004 r7 00000000
r8 80017f40 r9 0000ce48 10 418fcc28 fp 43ea95ac
ip 80559b38 sp bebfdff0 lr 8053250c pc 805557ac cpsr 20000010
#00 pc 000557ac /data/data/com.example.CoreTest/lib/
libcore.so
#01 lr 8053250c /data/data/com.example.CoreTest/lib/
libcore.so

code around pc:
8055578c 7fffccc4 7ffed398 7fffccd0 7ffed3ac
8055579c 7fffccdc 7ffed3c0 7fffcce8 7ffed3d4
805557ac 80a8b0b0 7ffed3ec 80a8b0b0 7ffed3f8
805557bc 80a8b0b0 7ffed410 7fffccdc 7ffed444
805557cc 7fffcce8 7ffed478 7fffccf4 7ffed4b0

code around lr:
805324ec e92d4010 e24dd010 e58d0004 e58d1000
805324fc e59d4004 e28d300c e1a00003 ebffe222
8053250c e28d300c e1a00004 e59d1000 e1a02003
8053251c ebffe253 e28d300c e1a00003 ebffe802
8053252c e59d3004 e1a00003 e28dd010 e8bd8010

stack:
bebfdfb0 00001000
bebfdfb4 bebfe01c
bebfdfb8 0029230c [heap]
bebfdfbc bebfe01c
bebfdfc0 7893f147
bebfdfc4 80533120 /data/data/com.example.CoreTest/lib/libcore.so
bebfdfc8 00000000
bebfdfcc 0029230c [heap]
bebfdfd0 00001000
bebfdfd4 bebfe014
bebfdfd8 0029230c [heap]
bebfdfdc bebfe014
bebfdfe0 00000100
bebfdfe4 80533120 /data/data/com.example.CoreTest/lib/libcore.so
bebfdfe8 df002777
bebfdfec e3a070ad
#00 bebfdff0 8054e0f0 /data/data/com.example.CoreTest/lib/libcore.so
bebfdff4 bebfe024
bebfdff8 bebfe03c
bebfdffc 8055ae6c /data/data/com.example.CoreTest/lib/libcore.so
bebfe000 80559734 /data/data/com.example.CoreTest/lib/libcore.so
bebfe004 805327ac /data/data/com.example.CoreTest/lib/libcore.so
bebfe008 8054e0f0 /data/data/com.example.CoreTest/lib/libcore.so
bebfe00c bebfe03c
bebfe010 b000d224
bebfe014 00001000
bebfe018 0029230c [heap]
bebfe01c 00001000
bebfe020 0029230c [heap]
bebfe024 b00105bc
bebfe028 b000d198
bebfe02c 8052d1d0 /data/data/com.example.CoreTest/lib/libcore.so
bebfe030 0000ffff [heap]
bebfe034 00000001
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

[alan]

have you looked up the address 000557ac with addr2line?

[Phillip Weisberg]

Alan, thanks for the suggestion. I did try using addr2line with
"libcore.so", but I was not able to resolve a function from the
address 0x000557ac.

I did some more digging and found the root of the problem. It turns
out that the crash is being caused by the allocation of a static data
member which uses the STL during instantiation. In my Windows
implementation, I am linking against the STL TR1 specification whereas
in the Android environment I am linking against the standard GNU STL
libraries (./android-ndk-r5b/sources/cxx-stl/gnu-libstdc++/include).
I will modify my project to use the GNU STL TR1 implementation
included in the NDK.

Thanks again for the help!

Cheers,
Phillip