> On 11 May 2016, at 10:37, Eric Heintzmann <[email protected]> wrote: > > > (gdb) thread 1 > [Switching to thread 1 (Thread 0x7ffff7f508c0 (LWP 1834))] > #0 0x00007ffff6925478 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/unix/sysv/linux/raise.c:55 > 55 in ../sysdeps/unix/sysv/linux/raise.c > (gdb) where > #0 0x00007ffff6925478 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/unix/sysv/linux/raise.c:55 > #1 0x00007ffff69268fa in __GI_abort () at abort.c:89 > #2 0x00007ffff6963fea in __libc_message (do_abort=do_abort@entry=2, > fmt=fmt@entry=0x7ffff6a59d11 "*** %s ***: %s terminated\n") > at ../sysdeps/posix/libc_fatal.c:175 > #3 0x00007ffff69eb357 in __GI___fortify_fail (msg=msg@entry=0x7ffff6a59cf9 > "stack smashing detected") at fortify_fail.c:31 > #4 0x00007ffff69eb320 in __stack_chk_fail () at stack_chk_fail.c:28 > #5 0x0000000000401abd in main () at basic.m:71 > > (gdb) thread 2 > [Switching to thread 2 (Thread 0x7ffff0d7a700 (LWP 1838))] > #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 > 225 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: No such > file or directory. > (gdb) where > #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 > #1 0x00007ffff785f066 in -[NSCondition waitUntilDate:] (self=<optimized > out>, _cmd=<optimized out>, limit=0x692f70) > at NSLock.m:384 > #2 0x00007ffff785deeb in -[NSConditionLock lockWhenCondition:beforeDate:] > (self=0x63f050, _cmd=<optimized out>, > condition_to_meet=1, limitDate=0x692f70) at NSLock.m:475 > #3 0x00007ffff78786d5 in -[NSOperationQueue(Private) _thread] > (self=0x63e8b0, _cmd=<optimized out>) at NSOperation.m:921 > #4 0x00007ffff78dd0b9 in nsthreadLauncher (thread=0x71b750) at > NSThread.m:1166 > #5 0x00007ffff6c9d454 in start_thread (arg=0x7ffff0d7a700) at > pthread_create.c:334 > #6 0x00007ffff69daeed in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
This tells us that thread 2 is waiting on a lock for the NSOperationQueue ... I think that's OK ... which means that the NSOperationQueue is still in existence (retained by the thread), so the problem is unlikely to be an inter-thread messaging issue. The main thread seems to have detected a stack error at line 71, which is right at the end of main() ... unfortunately, that doesn't give much clue about what might have clobbered the stack :-( You could try running the tests under valgrind to see if that gives any more information. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
