discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another unwinding problem on ARM


From: Mathias Bauer
Subject: Re: Another unwinding problem on ARM
Date: Thu, 13 Mar 2014 23:50:57 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]