Re: trying to debug problems with NSAutoreleasepool

Hi,
Richard Frith-Macdonald <richardtiptree.demon.co.uk>
wrote: 
> On 2007-11-27 14:01:43 +0000 "Sebastian
Reitenbach" 
> <sebastial00-bugdead-prods.de> wrote:
> 
> > Hi,
> > 
> > I try to figure out how that NSAutoreleasepool is
working, because I 
> > want to 
> > debug
> > some problems I have there while trying to get
opengroupware to run 
> > on 
> > gnustep-base. The webui application breaks in a
lot of places in 
> > NSAutoreleasepool.m:405
> > here the backtrace:
> 
> <snipped reasonable looking trace (though line
numbers make it look 
> like it's not a  current version of gnustep)>
The version installed is a 1.15.1, I'm pretty sure about
that,
maybe the line number offsets differ
by one or two, because I tried to add NSLog statements,
that I commented out instead of removing again.
That backtrace was from a segmentation fault, I was wrong
saying
it was an exception.

> 
> > I added a NSLog statement before that in the while
loop in 
> > -emptyPool, but 
> > that ended up in an endless loop, eating up all my
stack frames.
> 
> Sure ... NSLog autoreleases things ... likely to cause
difficulties in 
> the middle of emptying the current pool.
yes, now I know that too.

> 
> > in LSLoginAccountCommand.m, and in the other
places where it runs 
> > into that 
> > exception, the NSAutoreleasepool seems to be
handled like in other 
> > applications that work well.
> 
> What exception?
Sorry, exception was wrong, it just segfaults, without
exception. 
I ran it in gdb, and above backtrace was from that
segfault.

> 
> > Any idea what could be my problem or how I could
try to figure out?
> 
> You didn't say what your problem was ... the stacktrace
looked like a 
> normal emptying of a pool.
> Perhaps you have objects in the poolthat are crashing
when they are 
> released?
I think, that seems to be the case. but how do I find out
what kind of 
objects 
that are? The webui segfaults with the backtrace above, when
I think it is 
emptying the last object from the pool, not sure about that.
I do not 
fully understand what is going on there.
At least at ten places in opengroupware I commented out a 
[pool release]; or equivalent, to prevent these crashers.

As I doubt, that commenting out these lines, is the right
solution,
I tried to investigate the issue, to maybe find sth. better,
but for now
I got a bit stuck.

kind regards
Sebastian



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

On 2007-11-27 16:40:36 +0000 "Sebastian
Reitenbach" 
<sebastial00-bugdead-prods.de> wrote:

>> Perhaps you have objects in the poolthat are
crashing when they are 
>> released?
> I think, that seems to be the case. but how do I find
out what kind 
> of 
> objects that are? The webui segfaults with the
backtrace above, when 
> I think 
> it is emptying the last object from the pool, not sure
about that. I 
> do not 
> fully understand what is going on there.

Understandable ... the autorelease mechanism is pretty
performance 
critical, so it works hard to be fast and sacrifices some
readability 
for speed.  While emptying a pool, the code caches method 
implementations to avoid having to do multiple method
lookups for 
objects which are all of the same class.  It caches the 
implementations in a tiny hash table based on the address of
the class 
(shifted right a few bits to allow for the fact that classes
tend to 
be aligned on 4 or 8 byte boundaries, so the low few bits
are useless 
as a hash).

> At least at ten places in opengroupware I commented out
a [pool 
> release]; or 
> equivalent, to prevent these crashers.
> 
> As I doubt, that commenting out these lines, is the
right solution,
Almost certainly not ... that probably introduces a big
memory leak.

Most likely you have a problem with objects being released
more times 
than they are retained.

You can call [NSObject enableDoubleReleaseCheck: YES]; to
turn on some 
checking for this ... but it will slow down your code quite
a bit.

You can set the environment variable NSZombieEnabled to YES
... which 
will give you diagnostics about any attempt to use a
deallocated 
object, but will use lots of memory.
You can also set NSDeallocateZombies to YES to avoid leaking
memory as 
zombie objects, but this will give you less informative and
less 
reliable (the memory from a deallocated object could have
been re-used 
as another object) logging.



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustepgnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep