[bugs #11100] Hang on +dictionaryWithContentsOfURL:

[Richard Frith-Macdonald]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #11100] Latest Modifications:

Changes by: 
                Richard Frith-Macdonald <rfm@gnu.org>
'Date: 
                Tue 11/23/04 at 04:15 (GMT)

------------------ Additional Follow-up Comments ----------------------------
Thanks for the public URL.
I've tried using it with your test program, and it worked fine on my Debian 
GNU/Linux system.

So it looks like there may be a BSD specific problem... which is a problem for 
me as I don't have a BSD system to debug on.

You could try hacking base/Source/GSHTTPURLHandle.m to set the 'debug' flag 
when a handle is initialised so that your test program will log all I/O and you 
can get some idea of what is going on, but if that's not informative enough, 
the only real option I can see is either to insert lots of debugging statements 
in GSHTTPURLHandle.m or to step through under gdb to find out what is happening.









/**************************************************************************/
[bugs #11100] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=11100>
Project: GNUstep
Submitted by: 0
On: Mon 11/22/04 at 10:41

Category:  Base/Foundation
Severity:  5 - Average
Item Group:  Bug
Resolution:  Unreproducible
Privacy:  Public
Assigned to:  None
Status:  Open


Summary:  Hang on +dictionaryWithContentsOfURL:

Original Submission:  Using the attached program, I'm experiencing a hang when 
calling +dictionaryWithContentsOfURL:. The URL contains a serialized property 
list, with one key/value pair: Foo = Bar; .. OSX reads it fine. Each time I run 
it through gdb, and then kill it (sometimes after a few seconds, sometimes 
several minutes pass before I kill it), it always ends up in a different 
location. However, it does share one thing in common, in each instances where I 
break out of the program and examine the backtrace, everything is the same 
until the next call after -[NSRunLoop limitDateForMode:] (any that come after 
that, could be as shown below, or NSDefaultMallocZone(), etc). Output of 'bt' 
from one instance when I stopped it (see note above) is below:

(gdb) bt
#0  0x28354aef in gettimeofday () from /lib/libc.so.5
#1  0x28152035 in GSTimeNow () at NSDate.m:133
#2  0x28155340 in -[NSGDate timeIntervalSinceNow] (self=0x8305fa8, 
    _cmd=0x282ac110) at NSDate.m:1423
#3  0x281b5417 in -[NSRunLoop limitDateForMode:] (self=0x8305d28, 
    _cmd=0x282ac080, mode=0x282ac244) at NSRunLoop.m:1754
#4  0x281b615c in -[NSRunLoop runMode:beforeDate:] (self=0x8305d28, 
    _cmd=0x282b3aa0, mode=0x282ac244, date=0x8345188) at NSRunLoop.m:2035
#5  0x281eac61 in -[NSURL resourceDataUsingCache:] (self=0x80a0968, 
    _cmd=0x2829ba70, shouldUseCache=1 '01') at NSURL.m:1380
#6  0x2814955f in +[NSData dataWithContentsOfURL:] (self=0x2829b9e0, 
    _cmd=0x282af768, url=0x80a0968) at NSData.m:470
#7  0x281cc70c in -[NSString initWithContentsOfURL:] (self=0x806ec88, 
    _cmd=0x2829dfd8, url=0x80a0968) at NSString.m:1484
#8  0x28164026 in -[NSDictionary initWithContentsOfURL:] (self=0x80b0848, 
    _cmd=0x2829dfd8, aURL=0x80a0968) at NSDictionary.m:614
#9  0x28164312 in +[NSDictionary dictionaryWithContentsOfURL:] (
    self=0x2829de20, _cmd=0x8059150, aURL=0x80a0968) at NSDictionary.m:664
#10 0x0804b339 in main () at test.m:6
#11 0x0804b1b2 in _start ()

System is a FreeBSD 5.2.1 system, have only tested this with apple's Foundation 
on osx, and GNUstep's on FreeBSD. Works on apples, doesn't on GNUsteps.

Follow-up Comments
------------------


-------------------------------------------------------
Date: Tue 11/23/04 at 04:15         By: Richard Frith-Macdonald <CaS>
Thanks for the public URL.
I've tried using it with your test program, and it worked fine on my Debian 
GNU/Linux system.

So it looks like there may be a BSD specific problem... which is a problem for 
me as I don't have a BSD system to debug on.

You could try hacking base/Source/GSHTTPURLHandle.m to set the 'debug' flag 
when a handle is initialised so that your test program will log all I/O and you 
can get some idea of what is going on, but if that's not informative enough, 
the only real option I can see is either to insert lots of debugging statements 
in GSHTTPURLHandle.m or to step through under gdb to find out what is happening.




-------------------------------------------------------
Date: Mon 11/22/04 at 22:15         By: 0 <None>
I am using the CVS from a day and a half ago, and you may use 
http://www.fuqn.ca/foo.plist as a source of the property list I was using.

-------------------------------------------------------
Date: Mon 11/22/04 at 12:16         By: Richard Frith-Macdonald <CaS>
I can't reproduce this ... but there are variuos possibilities -

Various versions of NSURL have had problems with detecting the ends of 
responses with some pages from some web servers.
There are no known problems with the CVS version, but you don't say whether you 
are using up to date code from CVS or another version of GNUstep.

Unless there is a public URL that can be used to demonstrate  the problem with 
the latest code from CVS, my assumption would be that any torubles are already 
fixed in the current code.







File Attachments
-------------------

-------------------------------------------------------
Date: Mon 11/22/04 at 10:41  Name: test.m  Size: 317B   By: None
Simple test program used to create above problem.
http://savannah.gnu.org/bugs/download.php?item_id=11100&amp;item_file_id=1903






For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=11100>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/