discuss-gnustep
[Top][All Lists]
Advanced

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

Re: some gnustep-base tests are randomly failing


From: Sebastian Reitenbach
Subject: Re: some gnustep-base tests are randomly failing
Date: Fri, 28 Oct 2011 18:31:09 +0200
User-agent: SOGoMail 1.3.8

 
On Friday, October 28, 2011 18:21 CEST, Richard Frith-Macdonald 
<richard@tiptree.demon.co.uk> wrote: 
 
> 
> On 28 Oct 2011, at 15:44, Sebastian Reitenbach wrote:
> 
> > 
> > On Thursday, October 27, 2011 10:19 CEST, Richard Frith-Macdonald 
> > <richard@tiptree.demon.co.uk> wrote: 
> > 
> >> 
> >> On 26 Oct 2011, at 15:32, David Chisnall wrote:
> >> 
> >>> I was getting valgrind errors from something in the XML propertly list 
> >>> serialisation / user defaults stuff on program start a little while ago.  
> >>> It went away, so I assumed it was fixed, but it's possible that it just 
> >>> went away because the contents of my defaults changed...
> >>> 
> >>> I now see a valgrind error in dlopen() form NSBundle.  It seems to try 
> >>> reading 8 bytes past the end of the string returned by 
> >>> -fileSystemRepresentation.  I didn't have time to check if it's a bug in 
> >>> GNUstep or in libc yet.
> >>> 
> >>> David
> >>> 
> >>> On 26 Oct 2011, at 15:24, Sebastian Reitenbach wrote:
> >>> 
> >>>> Hi,
> >>>> 
> >>>> attached are a couple of backtraces of kind of randomly failing 
> >>>> gnustep-base tests. I tested on OpenBSD 5.0 -current i386. I tested the 
> >>>> following combinations, whichever doesn't matter:
> >>>> 
> >>>> gcc-4.2.1 with gcc system libobjc
> >>>> gcc-4.2.1 with libobjc2 svn
> >>>> clang-3.0rc1 with gcc system libobjc
> >>>> clang-3.0rc1 with libobjc2 svn
> >>>> 
> >>>> so the compiler doesn't seem to matter, nor which libobjc is used. For 
> >>>> me it seems that some buffers are read/written past its end.
> >> 
> >> I can't reproduce any problems here ... but I'd guess that the most likely 
> >> culprit for buffer overruns would be the changes I made recently to 
> >> support UTF-8 in string literals.  It could be that there's a system or 
> >> (more likely) locale specific bug to do with converting to/from UTF-8 in 
> >> some situation.
> > 
> > I found some time, trying to play with other locales so I did:
> > export LC_CTYPE='en_US.UTF-8'
> > and reran the testsuite for a couple of times. The random tests don't seem 
> > to fail anymore.
> 
> So what was the locale which *did* cause them to fail?
> If I know that, perhaps I can reproduce the problem.
> I'm away this weekend though, so I might not get round to looking at it until 
> some time next week.

before that, I did not had any LC_ or LANG or whatever variable set, so IIRC 
the default is just C on OpenBSD.

Sebastian


> 
 
 
 
 



reply via email to

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