Re: gnustep-base tests

[Eric Heintzmann]

Hi,

It's the -O2 optimization flags !!



make check OBJCFLAGS="-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security"

fails



make check OBJCFLAGS="-g -fstack-protector-strong -Wformat 
-Werror=format-security"

is fine

Le 11/05/2016 12:19, Richard Frith-Macdonald a écrit :
> > 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.