SIGSEGV error with limited stacktrace

[ThaMe90]

I am trying to natively buffer audio retrieved from the OpenSL ES API.
To do this, I implemented a simple Queue in my C file, which holds the
buffered data.
I then use a native pthread to pass the buffered data to the Java
layer, if there is enough buffered data (minimum of 3 buffered audio
frames, 1 frame = 30 ms audio).

However, while the native thread is waiting on data from the OpenSL ES
API, I get a SIGSEGV error message, with the native stacktrace.
However, I can't see where the error occurred, as the stacktrace is
incredibly useless.... This is because the program counter is not
displayed, only the registers.

08-30 14:09:51.148: INFO/DEBUG(21802): *** *** *** *** *** *** *** ***
*** *** *** *** *** *** *** ***
08-30 14:09:51.148: INFO/DEBUG(21802): Build fingerprint: 'samsung/GT-
I9000/GT-I9000:2.3.2/GINGERBREAD/XWJV1:user/release-keys'
08-30 14:09:51.148: INFO/DEBUG(21802): pid: 21803, tid: 21811 >>> w??
<<<
08-30 14:09:51.148: INFO/DEBUG(21802): signal 11 (SIGSEGV), code 1
(SEGV_MAPERR), fault addr fffc0000
08-30 14:09:51.148: INFO/DEBUG(21802): r0 405329c0 r1 fffc0000 r2
000001a0 r3 00000000
08-30 14:09:51.148: INFO/DEBUG(21802): r4 405329c0 r5 00000000 r6
002b5688 r7 000001e0
08-30 14:09:51.148: INFO/DEBUG(21802): r8 84b00dc5 r9 00000000 10
00100000 fp 00000001
08-30 14:09:51.148: INFO/DEBUG(21802): ip 822a5684 sp 46e6dea0 lr
8224b657 pc 8010dde8 cpsr 20000010
08-30 14:09:51.148: INFO/DEBUG(21802): d0 697320657565757a d1
6974696c69747565
08-30 14:09:51.148: INFO/DEBUG(21802): d2 6f696475412f733a d3
6f737365636f7220
08-30 14:09:51.148: INFO/DEBUG(21802): d4 006c006c00690068 d5
006100650074002e
08-30 14:09:51.148: INFO/DEBUG(21802): d6 006e0069006c006d d7
00730075002e006b
08-30 14:09:51.148: INFO/DEBUG(21802): d8 0000000000000000 d9
0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d10 0000000000000000 d11
0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d12 0000000000000000 d13
0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d14 0000000000000000 d15
0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d16 000000004052e0f8 d17
0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d18 0000000000000000 d19
0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d20 3fe0000000000000 d21
8000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d22 0000000000000000 d23
0000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d24 0000000000000000 d25
3ff0000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d26 0000000000000000 d27
3ff0000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d28 0000000000000000 d29
4000000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): d30 0000000000000000 d31
3fe0000000000000
08-30 14:09:51.148: INFO/DEBUG(21802): scr 60000012

This is the whole stacktrace... If anybody could point me to where I
could start with debugging this error? I know of the addr2line utility
provided by the NDK, but without a program counter, I can't determine
where the error occurred...

I've posted this message earlier @ StackOverflow (http://
stackoverflow.com/questions/7243315/sigsegv-error-with-limited-
stacktrace)

[mic _]

pc 8010dde8

/Michael

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[ThaMe90]

Tried that... didn't work. Addr2line tool reported ?? ??:0.

[mic _]

What lib did you run addr2line on? Just your own? If the address isn't found there maybe you could try other likely candidates, like libc and libopensles. Also did you try removing the initial 8 from the address?

/Michael

[ThaMe90]

I did only run it to my own library. How can I run it to more
libraries? I haven't done that before...

Yes I have tried removing the initial 8 from the address...

[Chris Stratton]

On Tuesday, August 30, 2011 10:44:47 AM UTC-4, ThaMe90 wrote:

Tried that... didn't work. Addr2line tool reported ?? ??:0.

On Aug 30, 4:41 pm, mic _ <mico...@gmail.com> wrote:
> pc 8010dde8

That's the actual address in the process memory space, you'll have to figure out the offset at which whatever component (ie, your ndk library, libc.so, or whatever) is loaded at, and subtract that - tools like ndk-stack depend on a dump where this has already been removed, rather than the 'register' value of pc which is still the full address. 

While the process still exists, you can obtain the list of components and their load offsets from /proc/pid/maps with sufficient permissions - perhaps you can have the program obtain that itself (from /proc/self/maps) and dump a copy to the sdcard, or run it on something unsecured such as the emulator, or use the run-as tool.   Or you can have your code log the address of a native function, from which you can deduce the load offset of your ndk .so, and maybe the same for something in libc, though that won't help you with the other libraries.  You might also look into running the ndk gdb.

Is your native thread properly registered with jni?

[ThaMe90]

I use the AttachCurrentThread and the DetachCurrentThread methods at
the beginning and end respectively of the ThreadStart method.

[ThaMe90]

Doh! Sometimes I can be so stupid... >.> How hard can it be to just
rerun Addr2Line with just another target... >.>

[ThaMe90]

After investigating further, I found that the error occurred in
libc.so. However, after finding the source on Google Code Search, I
found that the file that generated the error is in Assembly... -.-"

fchownat.S:

/* autogenerated by gensyscalls.py */
#include <sys/linux-syscalls.h>

.text
.type fchownat, #function
.globl fchownat
.align 4
.fnstart

fchownat:
mov ip, sp
.save {r4, r5, r6, r7}
stmfd sp!, {r4, r5, r6, r7}
ldmfd ip, {r4, r5, r6}
ldr r7, =__NR_fchownat
swi #0
ldmfd sp!, {r4, r5, r6, r7}
movs r0, r0
bxpl lr
b __set_syscall_errno
.fnend

Could anybody explain? My Assembly is not good to terrible...

[mic _]

All it does is save some registers on the stack, perform the fchownat syscall, restore the saved registers, and return (setting the errno first if the syscall returned an error).

/Michael

[ThaMe90]

I don't see why the fchownat syscall would be made, I don't do
anything with files.
How could it be triggered from my app when I don't do anything with
it?
But probably it's caused by the OS calling it. Though I can't see why
it crashes now all of a sudden...

[ThaMe90]

I seemed to have fixed this specific issue. I forgot to get a mutex on
the buffer queue I use for buffering audio. This specific issue might
have been solved, but now I get a new stacktrace. This time with a
specified stack though.

[ThaMe90]

Actually, it is the same error. Only now, I actually see the stack. It
seems that adding the mutex logic didn't help at all.

[ThaMe90]

In an effort to replicate the issue on the emulator, I initially got a
different error. After trying a second time though, I got the same
error as on the real device.
The new error occurred when I tried to pass data up to the Java layer
(along with a warning that a pointer used with the CallVoidMethod
wasn't a valid JNI value).

The original issue seems to arise when I try to pull data from my
buffer. I guess a system call to fchownat could give an error if the
buffer is shared between different threads without proper
synchronization. However, I already synchronized it with the mutex I
was talking about earlier. :/

[ThaMe90]

Apparently, the whole issue was resolved by re-adjusting my
synchronization logic for the buffer I use between the two threads.
By only synchronizing the really critical pieces of code, the error
went away (Should have done that in the beginning, as I've been
taught)...

Anyway, problem solved!

> > > > > > > > > > > > For more options, visit this group at...
>
> read more »