[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSDate oddity
From: |
Michael Scheibler |
Subject: |
Re: NSDate oddity |
Date: |
Fri, 4 May 2001 08:41:31 +0200 |
From: "Richard Frith-Macdonald" <richard@brainstorm.co.uk>
Sent: Thursday, May 03, 2001 10:04 PM
>
> On Thursday, May 3, 2001, at 02:43 PM, David Relson wrote:
>
> > Greetings!
> >
> > I'm using gnustep-base-1.0.0 with linux-2.4.4 on top of a Mandrake 8.0
> > distribution and have noticed an odd interaction between NSCalendarDate
> > and gdb. The test case is trival - a program that creates 2 or more
> > NSCalendarDate objects (and formats them as does NSLog()). Run from
> > the command line, the program output is fine. Run inside gdb, the
> > first date is garbled.
> >
> > Anybody familiar with this anomaly or know what causes it?
> >
> > The problem was initially noticed when using NSLog() calls in a large,
> > multithreaded program. However, for once, the problem reduced nicely
> > to a nearly trivial program.
> >
> > FWIW, I've attached the program (date.m) and two output files -
> > prog.out and gdb.out
>
> I tried your test ... and couldn't reproduce the problem.
>
> This sort of thing (code behaving differently under gdb) is usually
> related to
> problems with uninitialised variables, where the use of gdb chanbges the
> memory layout
> so that a variable that normally happens to contain one value now
> contains another.
>
> If this is the problem, any change at all to libraries etc could make
> the problem
> disappear, and it would be unsurprising that I couldn't reproduce it.
>
> I'd be really interested if you could step through the creation and
> display of the
> first date under debug, and perhaps find out where things go wrong.
>
I have problems, too, with different behaviour in gdb to running the app
from command line. But my problem is becoming really serious. I can't debug
at all because gdb stops with a SIGSEGV fault just after starting the
application.
It happens when the objc runtime loads all the classes into its class tree.
The error occurs in sarray_free()
429 #else /* OBJC_SPARSE2 */
- 430 struct sbucket* bkt = array->buckets[counter];
- 431 if ((bkt != array->empty_bucket) &&
432 (bkt->version.version == array->version.version))
// btk->version.version => Access violation
433 {
- 434 sarray_free_garbage(bkt);
- 435 nbuckets -= 1;
- 436 }
437 #endif
As you already mentioned even a small change let the problem - well,
unfortunately not disappear, but occur when loading another module.
Is there a bug in libobjc?
Michael