ndk-gdb illegal instruction in linker thread

[Jason Mallios]

We recently upgraded to r8b from r6b in order to get our 4.1 devices debugging, but now our 2.3.4 devices won't debug.  Both the 4.4.3 and 4.6 toolchains have this problem.  One device is an HTC Desire HD.  My host is a Mac with OS X 10.7.3.  Our multi-threaded app's target is android-10, and we're using sdk tools 20.0.1 and platform-tools 14.

Running gdb verbosely, everything looks fine.  At the initial break, if I continue, I receive:

(gdb) c

Continuing.

[New Thread 15717]

Program received signal SIGILL, Illegal instruction.

[Switching to Thread 15717]

0xb00055bc in ?? () from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/linker

The stack is corrupted:

(gdb) bt

#0  0xb00055bc in ?? ()

   from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/linker

#1  0x00100000 in ?? ()

#2  0x00100000 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?) 

There are 10 threads at this point:

(gdb) info threads

[New Thread 15705]

[New Thread 15706]

[New Thread 15707]

[New Thread 15708]

[New Thread 15709]

[New Thread 15710]

[New Thread 15711]

[New Thread 15716]

  Id   Target Id         Frame 

  10   Thread 15716      0xafd0c868 in __futex_syscall3 ()

   from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/libc.so

  9    Thread 15711      0xafd0b82c in __ioctl ()

   from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/libc.so

  8    Thread 15710      0xafd0b82c in __ioctl ()

   from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/libc.so

  7    Thread 15709      0xafd0c868 in __futex_syscall3 ()

   from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/libc.so

  6    Thread 15708      0xafd0b974 in select ()

   from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/libc.so

  5    Thread 15707      0xafd0c11c in __rt_sigtimedwait ()

   from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/libc.so

  4    Thread 15706      0xafd0c868 in __futex_syscall3 ()

   from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/libc.so

  3    Thread 15705      0xafd0c868 in __futex_syscall3 ()

   from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/libc.so

* 2    Thread 15717      0xb00055bc in ?? ()

   from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/linker

  1    Thread 15704      0xafd0c868 in __futex_syscall3 ()

   from <MY_PROJECT_DIR>/android/debug/obj/local/armeabi-v7a/libc.so

No errors in the logcat.  Switching back to r6b debugs fine.  Any ideas how to figure this out? 

Thx,

Jason

[Ian Ni-Lewis]

Can you confirm that the gdbserver on your 2.3 device is the new one from r8b and not the old one from r6b?

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/7_my9F8_w-AJ.
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.

--
Ian Ni-Lewis

Developer Advocate
Android Developer Relations

[Jason Mallios]

On Monday, August 6, 2012 4:20:11 PM UTC-7, Ian Ni-Lewis wrote:

Can you confirm that the gdbserver on your 2.3 device is the new one from r8b and not the old one from r6b?

Sure, my device's gdbserver got from:

adb pull /data/data/<MY_PACKAGE>/lib/gdbserver

is indeed binary-equivalent to:

android-ndk-r8b/prebuilt/android-arm/gdbserver/gdbserver

but different from:

android-ndk-r6b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/gdbserver

[Andrew Hsieh]

Could you confirm:

1. Does r8b gdb work for 4.1 devices for the same app?

2. Could you debug app built by r6b with gdb/gdbserver in r8b, and vice versa?

Not sure if this helps: r8b toolchain enables NX bit and relro/bind_now protections by default.  Maybe it worth a try to disable both with the following:

    LOCAL_DISABLE_NO_EXECUTE=true  # disable "--noexecstack" and "-z noexecstack"

    DISABLE_RELRO=true             # disable "-z relro" and "-z now"

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/0RwveXetOQoJ.

[Jason Mallios]

1. Does r8b gdb work for 4.1 devices for the same app?

Yes, same app.  I have a Nexus S running 4.1.1 that debugs fine using r8b.

 

2. Could you debug app built by r6b with gdb/gdbserver in r8b, and vice versa?

I'm not sure what this proves or of the best way to do this.  But, what I did was alter r6b, manually replacing the arm-linux-androideabi-4.4.3 prebuilt version of gdbserver with r8b's android-arm gdbserver.  I then built a debug version of the app using r6b and installed it to my 2.3.4 device.  I verified the r8b version of gdbserver existed in /data/data/<MY_PACKAGE>/lib/gdbserver.  Then, I ran ndk-gdb from r8b, and got the same Illegal instruction.

 

Not sure if this helps: r8b toolchain enables NX bit and relro/bind_now protections by default.  Maybe it worth a try to disable both with the following:

    LOCAL_DISABLE_NO_EXECUTE=true  # disable "--noexecstack" and "-z noexecstack"

    DISABLE_RELRO=true             # disable "-z relro" and "-z now"

These did not help (used LOCAL_DISABLE_RELRO instead of DISABLE_RELRO).  Still a SIGILL and a linker thread with a corrupt stack. 

[Jason Mallios]

I'm able to get a better-looking callstack if I set a break at:

(gdb) b android_native_app_glue.c:android_app_set_activity_state 

Breakpoint 1 at 0x80c69b28: file <MY_NDK_R8B>/sources/android/native_app_glue/android_native_app_glue.c, line 314.

(gdb) c

Continuing.

Breakpoint 1, android_app_set_activity_state (android_app=0x371018, cmd=11 '\v')

    at <MY_NDK_R8B>/sources/android/native_app_glue/android_native_app_glue.c:314

314    pthread_mutex_lock(&android_app->mutex);

(gdb) bt

#0  android_app_set_activity_state (android_app=0x371018, cmd=11 '\v')

    at <MY_NDK_R8B>/sources/android/native_app_glue/android_native_app_glue.c:314

#1  0x80c69c86 in onResume (activity=0x370f00)

    at <MY_NDK_R8B>/sources/android/native_app_glue/android_native_app_glue.c:349

#2  0xad337ba4 in ?? ()

#3  0xad337ba4 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Then step to the next instruction:

(gdb) si

Program received signal SIGILL, Illegal instruction.

0x80c69b2c in android_app_set_activity_state (android_app=0x371018, cmd=11 '\v')

    at <MY_NDK_R8B>/sources/android/native_app_glue/

android_native_app_glue.c:314

There's the bad instruction.  Before the SIGILL, my program counter is at:

pc             0x80c69b28       0x80c69b28 <android_app_set_activity_state+12>

At the SIGILL, it's at:

pc             0x80c69b2c       0x80c69b2c <android_app_set_activity_state+16>

but, according to the asm layout:

     │0x80c69b24 <android_app_set_activity_state+8>   strb.w r3, [sp, #3]

B+ │0x80c69b28 <android_app_set_activity_state+12>  ldr    r3, [sp, #4]

     │0x80c69b2a <android_app_set_activity_state+14>  add.w  r3, r3, #64     ; 0x40

0x80c69b2c is clearly illegal.  The next instruction is a 0x80c69b2a.  So, why is the program counter incrementing by 0x4 instead of 0x2?

[Andrew Hsieh]

Thanks for detailed info.  It appears that gdb 7.3.x computes wrong next breakpoint address at the presence of thumb2 code.  Could you:

1. confirm that the gdb 7.3.x single-step fine the same app on 4.1 devices

2. try if the same behavior happen in 2.3.4 emulator as well

3. open a bug at http://code.google.com/p/android/issues/list to track this issue

I can see the exact thumb2 code around android_app_set_activity_state.  I will modify a sample native-activity app and try to reproduce the issue in the meantime.

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/x7sF18ZX-pYJ.

[Jason Mallios]

1. confirm that the gdb 7.3.x single-step fine the same app on 4.1 devices

The 4.1 device steps over single instructions successfully. 

 

2. try if the same behavior happen in 2.3.4 emulator as well

I could not get the 2.3.3 emulator to debug the app with arm v7a instructions.  I got the following gdb error:

ndk-gdb --start --force --verbose

Android NDK installation path: <MY_NDK_R8B>

Using default adb command: <MY_SDK>/platform-tools/adb

ADB version found: Android Debug Bridge version 1.0.29

Using ADB flags: 

Using auto-detected project path: .

Found package name: <MY_PACKAGE>

ABIs targetted by application: armeabi-v7a

Device API Level: 10

Device CPU ABI: armeabi

ERROR: The device does not support the application's targetted CPU ABIs!

       Device supports:  armeabi 

       Package supports: armeabi-v7a

I do not see a system image for arm v7a for 2.3.3 listed in the sdk manager.  Are you sure this is possible?

 

3. open a bug at http://code.google.com/p/android/issues/list to track this issue

I can see the exact thumb2 code around android_app_set_activity_state.  I will modify a sample native-activity app and try to reproduce the issue in the meantime.

http://code.google.com/p/android/issues/detail?id=36149 

I used the native-activity as the repro case, since I also get a SIGILL single-instruction stepping thru it.

[Andrew Hsieh]

Your are right.  The pre-ICS ARM system images in SDK can't handle armeabi-v7a *so.  I will make do with what we have and update http://code.google.com/p/android/issues/detail?id=36149 .  Thanks!

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/4GNJOZ4CYmcJ.