discuss-gnustep
[Top][All Lists]
Advanced

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

Re: MallocDebug oddities /w GNUstep on Darwin


From: Nicola Pero
Subject: Re: MallocDebug oddities /w GNUstep on Darwin
Date: Fri, 19 Jul 2002 12:48:11 +0100 (BST)

> > I told about this on March 20th on the GNUstep bug list but 
> > obviously neither the patch provided there nor any other 
> > solution made it into the sources.
> > 
>
> Looking at the gnustep-base Source, there is no NSLog in NSException - the
> gnustep's _NSFoundationUncaughtExceptionHandler() is *already* using
> fprintf.
> 
> So I think your remark/change/patch did make it into the gnustep-base
> sources.  It didn't make it into Apple's Foundation - but that's not our
> problem :-)

I went to search for your original post, and I see you suggested a totally
unrelated change to prevent a different type of recursive exceptions ...
which has not indeed made it into the library.

The problem I can see with your patches is that ... it's a very
interesting problem, but I don't see a good solution ... the best solution
I can see is ... to leave it as it is :-)

Trying just to prevent all recursive exceptions is not a solution, since
it would also prevent legitimate recursive exceptions - such as for
example if NSException +raise:format:arguments: is called with invalid
format, arguments, and during raising of the exception, the invalid
format, arguments cause another (different) exception to be raised because
of the invalid format, arguments.  I think it's absolutely legimitate to
raise the recursive exception here (and recursion would not be infinite).

Trying to store the latest recursive exception name and preventing any
recursive exception with the name is no solution either, since a
legitimate recursive exception might have the same name, yet be a
different exception.  Also, you would need to lock the saved last name
against thread problems, and then are we sure we are not causing more
problems than we are fixing by getting into this complication ? :-)

The only case I can imagine in which you get the infinite recursive
exception is if your gnustep-base library is broken - actually the only
real case I can think of is if your NSString class is totally broken - a
basic NSConstantString problem ? - in which case the program would
normally not even start :-)

Anyway - if you think you really have a great patch to work around this
problem (and you can show me a real case - different from a broken
NSConstantString - where it would prevent a crash due to an infinite stack
loop), please let me know - I'll be happy to have it applied.




reply via email to

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