discuss-gnustep
[Top][All Lists]
Advanced

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

Re: gnustep-base tests


From: Eric Heintzmann
Subject: Re: gnustep-base tests
Date: Wed, 11 May 2016 23:09:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.2

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 <address@hidden> wrote:


(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff7f508c0 (LWP 1834))]
#0  0x00007ffff6925478 in __GI_raise (address@hidden) at 
../sysdeps/unix/sysv/linux/raise.c:55
55      in ../sysdeps/unix/sysv/linux/raise.c
(gdb) where
#0  0x00007ffff6925478 in __GI_raise (address@hidden) at 
../sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007ffff69268fa in __GI_abort () at abort.c:89
#2  0x00007ffff6963fea in __libc_message (address@hidden, address@hidden "*** %s 
***: %s terminated\n")
    at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff69eb357 in __GI___fortify_fail (address@hidden "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.





reply via email to

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