title: SIGSEGV error with limited stacktrace
body: <p>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).</p>
  
  <p>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.</p>
  
  <pre><code>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  &gt;&gt;&gt; w�� &lt;&lt;&lt;
  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
  </code></pre>
  
  <p>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...</p>
  
  <h2>Update</h2>
  
  <p>As per the suggestions given @ <a href="http://groups.google.com/group/android-ndk/browse_thread/thread/d7fe50f356f50896#" rel="nofollow">http://groups.google.com/group/android-ndk/browse_thread/thread/d7fe50f356f50896#</a>, I've been able to further investigate the issue. After using the Addr2Line tool on the libOpenSLES.so and libc.so, I got a hit with libc.so. However, the file in question is one automatically generated by python and is written in Assembly. It is however, a System Call. The file I speak of is fchownat.S:</p>
  
  <pre><code>/* autogenerated by gensyscalls.py */
  #include &lt;sys/linux-syscalls.h&gt;
  
      .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
  </code></pre>
  
  <p>Anybody got an idea on why it would crash here? Better yet, could anybody explain what it actually does? From what I found, it is a System Call to change ownership of a file... But I can't understand that from the code... My Assembly skillz are none to terrible...</p>