Re: gnustep-base tests

[Richard Frith-Macdonald]

> 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.