Re: gnustep-base tests

[Eric Heintzmann]

Le 11/05/2016 10:34, Richard Frith-Macdonald a écrit :
> > On 11 May 2016, at 09:14, Eric Heintzmann <heintzmann.eric@free.fr> wrote:
> >
> >
> >
> > Le 11/05/2016 08:58, Richard Frith-Macdonald a écrit :
> > > > On 10 May 2016, at 23:15, Eric Heintzmann <heintzmann.eric@free.fr> 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 (sig=sig@entry=6)
> >     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 (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) 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 (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:55

(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