On 11 May 2016, at 10:37, Eric Heintzmann <heintzmann.eric@free.fr> 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.