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 11:37:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.2



Le 11/05/2016 10:34, Richard Frith-Macdonald a écrit :
On 11 May 2016, at 09:14, Eric Heintzmann <address@hidden> wrote:



Le 11/05/2016 08:58, Richard Frith-Macdonald a écrit :
On 10 May 2016, at 23:15, Eric Heintzmann <address@hidden> wrote:



Le 10/05/2016 11:41, Richard Frith-Macdonald a écrit :
On the one hand, the particular number format stuff is rarely used, so a bug 
there may not be important (and may depend on the particular ICU library 
shipped on the system).
Well I ve done some tests and this particular problem is common to debian 
testing (stretch)  and unstable (sid) and Ubuntu 16.04 too...
On the other, we really want to fix *any* failure of the regression tests.
Does the same problem occur with gnustep-base from svn trunk?
Can you get a stack trace of the crash?

Well I ve tried to use gnustep-make 2.6.6-3 to build gnustep-base 1.24.9 and 
the regrssesion test ar ok !!
It seem the bug is in gnustep-make 2.6.8 (or in the packaging)
While I don't remember anything significant changng, I guess there might have 
been a change in the test framework code which could have exposed a bug in the 
library  not noticed in the older version or something.  I think we need stack 
traces from gdb (ie full symbolic information) to find out where the issue is.  
It's also strange that nobody else is seeing it.
I'm going to try installing a new debian system to see if I can reproduce it, 
but that's going to take quite some time, and I don't think the chances are 
very good (too many unknown variables).

I've started to play with gdb.
After the crash there are these strange lines:

Program received signal SIGABRT, Aborted.
0x00007ffff6925478 in __GI_raise (address@hidden)
    at ../sysdeps/unix/sysv/linux/raise.c:55
55      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
I'd guess that's the last frame of the stack, showing the final part of lthe 
process crashing... the interesting information would be further up the stack.


(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) info thread
  Id   Target Id         Frame
2 Thread 0x7ffff0d7a700 (LWP 1838) "basic" pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
* 1 Thread 0x7ffff7f508c0 (LWP 1834) "basic" 0x00007ffff6925478 in __GI_raise (address@hidden)
    at ../sysdeps/unix/sysv/linux/raise.c:55

(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



reply via email to

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