[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
>
- Re: some gnustep-base tests are randomly failing, (continued)
- Re: some gnustep-base tests are randomly failing, Richard Frith-Macdonald, 2011/10/27
- Re: some gnustep-base tests are randomly failing, Sebastian Reitenbach, 2011/10/28
- Re: some gnustep-base tests are randomly failing, Fred Kiefer, 2011/10/28
- Re: some gnustep-base tests are randomly failing, Sebastian Reitenbach, 2011/10/28
- Re: some gnustep-base tests are randomly failing, Richard Frith-Macdonald, 2011/10/28
- Re: some gnustep-base tests are randomly failing, Fred Kiefer, 2011/10/28
- Re: some gnustep-base tests are randomly failing, Richard Frith-Macdonald, 2011/10/28
- Re: some gnustep-base tests are randomly failing, Fred Kiefer, 2011/10/29
- Re: some gnustep-base tests are randomly failing, Stefan Bidi, 2011/10/28
- Re: some gnustep-base tests are randomly failing, Richard Frith-Macdonald, 2011/10/28
- Re: some gnustep-base tests are randomly failing,
Sebastian Reitenbach <=