Re: Another unwinding problem on ARM

[Mathias Bauer]

Hi,

some more information about the crash in the threads.m test case of the 
GNUstep NSOperation tests.

The first thread in the test has the following stack to unwind:

> #0  __pthread_exit (value=0x0) at pthread_exit.c:26
> #1  0xb6d1939c in +[NSThread exit] (self=0xb6f94ee0 <_OBJC_CLASS_NSThread>,
>     _cmd=0xb6f950b0 <.objc_selector_list+80>) at NSThread.m:535
> #2  0xb6d1aeac in nsthreadLauncher (thread=0x10f598) at NSThread.m:811
> #3  0xb67371da in start_thread (arg=0xb4b10450) at pthread_create.c:311
> #4  0xb4d66b8c in ?? ()
>     at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92

It does it by calling the standard PRs in libgcc and the stop funtion in 
libpthread 4 times and then finally by finishing with a long jump in 
unwind_stop (in libpthread).

For me that is as expected.

The second thread looks differently:

> #0  __pthread_exit (value=0x0) at pthread_exit.c:26
> #1  0xb6d1939c in +[NSThread exit] (self=0xb6f94ee0 <_OBJC_CLASS_NSThread>,
>     _cmd=0x1c8f0 <.objc_selector_list+96>) at NSThread.m:535
> #2  0x0000a408 in -[OpExit main] (self=0x100478,
>     _cmd=0xb6f821c0 <.objc_selector_list+160>) at threads.m:92
> #3  0xb6c7e1d4 in -[NSOperation start] (self=0x100478,
>     _cmd=0x1c930 <.objc_selector_list+160>) at NSOperation.m:463
> #4  0xb6c79a08 in -[NSObject performSelector:withObject:] (self=0x100478,
>     _cmd=0xb6f951d0 <.objc_selector_list+368>,
>     aSelector=0x1c930 <.objc_selector_list+160>, anObject=0x0)
>     at NSObject.m:2046
> #5  0xb6d1a498 in -[NSThread main] (self=0x113268,
>     _cmd=0xb6f95098 <.objc_selector_list+56>) at NSThread.m:743
> #6  0xb6d1ae7c in nsthreadLauncher (thread=0x113268) at NSThread.m:809
> #7  0xb67371da in start_thread (arg=0xb41ff450) at pthread_create.c:311
> #8  0xb4d66b8c in ?? ()
>     at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92

This time again standard PRs in libgcc are used 4 times, but then a 
different PR is used. This PR does  return neither INSTALL_CONTEXT nor 
CONTINUE_UNWIND, thus the unwind function returns to pthread_exit, 
causing the app to abort.

The PR is taken from the EHT of that frame. The offset points into 
libgnustepbase, the PR of the Objective-C runtime is not called.
OTOH in the same test case on Linux X86_64 the PR in libobjc2 *is* 
called at this point. Is it possible that there is still something funky 
in the EHT entries of Objective-C code?

Regards,
Mathias

Am 11.03.14 13:39, schrieb Mathias Bauer:
> Hi dear list members,
>
> the tests in GNUstep base revealed another problem that is related to
> unwinding. libobjc2 and gnustep base have been built with the latest
> llvm/clang trunk version and with -fobjc_runtime=gnustep-1.7.
>
> The test core/base/Tests/base/NSOperation/obj/threads produces a crash
> when a thread is exited.
>
> The first thread in this test case that was exited seemed to get
> unwinded somehow. This is the call stack I got before it ended:
>
> > #0  0xb4fcb064 in siglongjmp () from /lib/libc.so.6
> > #1  0xb651a3d0 in unwind_stop () from /lib/libpthread.so.0
> > #2  0xb50f4808 in ?? () from /lib/libgcc_s.so.1
> > #3  0xb50f5550 in _Unwind_ForcedUnwind () from /lib/libgcc_s.so.1
> > #4  0xb651cb64 in _Unwind_ForcedUnwind () from /lib/libpthread.so.0
> > #5  0xb651a47c in __pthread_unwind () from /lib/libpthread.so.0
> > #6  0xb6513f40 in pthread_exit () from /lib/libpthread.so.0
> > #7  0xb6d0c99c in +[NSThread exit] (self=0xb6f8c4b0
> > <_OBJC_CLASS_NSThread>, _cmd=0xb6f8c6d8 <.objc_selector_list+168>) at
> > NSThread.m:535
> > #8  0xb6d0e4a4 in nsthreadLauncher (thread=0x10fca0) at NSThread.m:811
> > #9  0xb6512e2c in start_thread () from /lib/libpthread.so.0
>
> The personality routine in libobjc2 was not called here. It is called
> however if I do the same test on Linux X86_64.
>
> Shouldn't we expect that the Objective-C personality routine will be
> called on ARM also?
>
> For me it looks as if the stack unwinding was ended prematurely, before
> a stack frame with Objective-C code was hit. But it may be just my
> limited understanding that lets me think so.
>
> The second thread to be exited hits a breakpoint in unwind_stop several
> times and then finally ends up in a SIGABRT:
>
> > #0  0xb4fcb240 in raise () from /lib/libc.so.6
> > #1  0xb4fcc66c in abort () from /lib/libc.so.6
> > #2  0xb651a480 in __pthread_unwind () from /lib/libpthread.so.0
> > #3  0xb6513f40 in pthread_exit () from /lib/libpthread.so.0
> > #4  0xb6d0c99c in +[NSThread exit] (self=0xb6f8c4b0
> > <_OBJC_CLASS_NSThread>, _cmd=0x1c8b0 <.objc_selector_list+32>) at
> > NSThread.m:535
> > #5  0x0000a810 in -[OpExit main] (self=0x1001b8, _cmd=0xb6f79738
> > <.objc_selector_list+312>) at threads.m:92
> > #6  0xb6c70cf0 in -[NSOperation start] (self=0x1001b8, _cmd=0x1c8f8
> > <.objc_selector_list+104>) at NSOperation.m:463
> > #7  0xb6c6be10 in -[NSObject performSelector:withObject:]
> > (self=0x1001b8, _cmd=0xb6f8c720 <.objc_selector_list+240>,
> > aSelector=0x1c8f8 <.objc_selector_list+104>, anObject=0x0) at
> > NSObject.m:2046
> > #8  0xb6d0da90 in -[NSThread main] (self=0x113960, _cmd=0xb6f8c638
> > <.objc_selector_list+8>) at NSThread.m:743
> > #9  0xb6d0e474 in nsthreadLauncher (thread=0x113960) at NSThread.m:809
> > #10 0xb6512e2c in start_thread () from /lib/libpthread.so.0
>
> Does someone have an idea for the reason of that or where to look to get
> more information about possible root causes ?
>
> Regards,
> Mathias
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep