Re: Exception handling with NSURL

[Richard Frith-Macdonald]

On 2007-12-06 12:30:54 +0000 Philippe Roussel <address@hidden> wrote:

> Le jeudi 06 décembre 2007 à 10:59 +0000, Richard Frith-Macdonald a
> écrit :
>> On 2007-12-06 09:51:35 +0000 Philippe Roussel <address@hidden> wrote:
>>> Well, I have to disagree : see NSURL.m line 837. I want to type
>>> http://philou:address@hidden/ but when parsing philou: NSURL thinks it's
>>> a hostname followed by a port and is expecting a numeric value.
>> 
>> My thought was ... Line 837 of NSURL.m is only reached when checking the 
>> port part of the URL, and since there is no port part in your example 
>> string, it can only be reached from parsing a different URL string.
>> 
>> However, I just realised that you are probably actually talking about 
>> validating a whole set of URLs as you add a character at a time to the 
>> length ... 'h', then 'ht' then 'htt' then 'http' then 'http:' and so on.
>> When you get to 'http://philou:' the code will be assuming that 'philou' is 
>> a host name because there is no '@' sign present to tell it that it's 
>> actually a username and password followed by a host.  It therefore assumes 
>> that what comes after the colon is a port (and it's correct to do so, 
>> because that's what the RFCs tell us).
> 
> Yes, sorry I wasn't clear enough. I'm using this to enable/disable the
> "Ok" button of a dialog for each modificaton in a TextField. I just
> didn't find another (easy) way to know if a String is a valid url.
> 
> I know http://philou: isn't valid and I would like URLWithString: to
> return nil as documented.

Well it does ... unless the program crashes first :-)

>>> My code used to function (NSURL URLWithString returning nil with a non
>>> valid string) until I updated to trunk yesterday or two days ago. 
>> PS. -initWithString:relativeToURL: should only be exiting with an exception 
>> if you passed it a nil argument.  All the other error checking just results 
>> in a nil value returned.  This somewhat inconsistent behavior is copying 
>> the MacOS-X implementation behavior (I don't believe an initialisation 
>> method should ever raise an exception).  I've modified the logging to 
>> refrain from printing the diagnostics unless debug is explicitly turtned 
>> on.
>> 
>> Anyway, I can't see why any of this should cause a coredump ... perhaps you 
>> could print a stack trace in gdb to show where/why your app is dumping?
> 
> Here it is (URLWithString is called with @"http://philou:c";) :
> 
> #0  0xb7924c3d in GSPrivateStackAddresses () at NSDebug.m:1145
> #1  0xb7938c09 in -[NSException raise] (self=0x857e8c0, _cmd=0xb7b6c548)
> at NSException.m:817
> #2  0xb793876e in +[NSException raise:format:arguments:]
> (self=0xb7b6c340, _cmd=0xb7b6c530, name=0xb7b6c0e4, format=0xb7b9b11c,    
> argList=0xbfb7a150 "�z9\b\020O3\bH[L\b") at NSException.m:760
> #3  0xb79386a6 in +[NSException raise:format:] (self=0xb7b6c340,
> _cmd=0xb7b9b5d0, name=0xb7b6c0e4, format=0xb7b9b11c) at
> NSException.m:746
> #4  0xb79f26c1 in -[NSURL initWithString:relativeToURL:]
> (self=0x85197d8, _cmd=0xb7b9b600, aUrlString=0x84c5b48, aBaseUrl=0x0) at
> NSURL.m:850
> #5  0xb79f1bec in -[NSURL initWithString:] (self=0x85197d8,
> _cmd=0xb7b9b5f8, aUrlString=0x84c5b48) at NSURL.m:619
> #6  0xb79f162d in +[NSURL URLWithString:] (self=0xb7b9b580,
> _cmd=0x8077300, aUrlString=0x84c5b48) at NSURL.m:509
> #7  0x0805e3fc in -[iCalStoreDialog controlTextDidChange:]
> (self=0x847fc10, _cmd=0xb7f29d08, notification=0x849a598) at
> iCalStore.m:62
> #8  0xb796f151 in -[NSNotificationCenter _postAndRelease:]
> (self=0x80bbe40, _cmd=0xb7b7af08, notification=0x849a598) at
> NSNotificationCenter.m:1067
> #9  0xb796f6d8 in -[NSNotificationCenter
> postNotificationName:object:userInfo:] (self=0x80bbe40, _cmd=0xb7ec94a8,
> name=0xb7f46470,    object=0x845d180, info=0x82df438) at 
> NSNotificationCenter.m:1126
> #10 0xb7cd9da8 in -[NSControl textDidChange:] (self=0x845d180,
> _cmd=0xb7f29df8, aNotification=0x856cc08) at NSControl.m:567
> 
> [snip]
> 
> It could be something wrong in my code but I haven't changed it in a
> long time and it used to work fine.

Thanks ...looks like it's crashing while trying to find the callstack return 
addresses.

1. Could you please let me know what signal is causing the crash ... this code 
has a signal handler to trap segmentation violations caused by a known bug in 
gcc, but maybe the gcc function to provide return addresses can crash in ways 
other than a segmentation violation.

2. Could you also try updating from svn ... I just recently added a check to 
try to limit the number of return addresses we look up to 2 less than the 
reported number of stack frames, in the hope of avoiding encountering the bug 
in gcc's __builtin_return_address() function altogether.  It may be that this 
will have fixed your problem.