Re: [[NSDate alloc] initWithString] crashes with valid string

[Matt Neuburg]

On Tue, 15 Jul 2008 11:36:46 -0700, Markus Spoettl
<[EMAIL PROTECTED]> said:
>Hi List,
>
>   I've a problem I am failing to track down (let alone understand)
>for a couple of weeks now. My application imports XML files that
>contain - amongst other things - dates. Once in a while, the string to
>date conversion causes a crash (EXC_BAD_ACCESS):
>
>#0 0x90b1da14 in ures_getIntVector
>#1 0x90b20eb0 in icu::Calendar::setWeekCountData
>#2 0x90b1f463 in icu::GregorianCalendar::GregorianCalendar
>#3 0x90b1ee16 in icu::Calendar::createInstance
>#4 0x90b1c73e in ucal_open
>#5 0x940a097b in __CFCalendarCreateUCalendar
>#6 0x940a0a22 in __CFCalendarSetupCal
>#7 0x940a15d7 in _CFCalendarComposeAbsoluteTimeV
>#8 0x95428cbc in -[NSCFCalendar dateFromComponents:]
>#9 0x9542879b in -[NSDate(NSDate) initWithString:]
>
>This specific crash happened with the string: "2008-05-09 19:47:47
>+", which seems perfectly valid input for NSDate -initWithString:.

This is not really relevant, but I just wanted to mention that I have found
string-to-date conversion extraordinarily touchy. In 2003 I filed a bug
pointing out that given a string @"Thu, 3 Jul 2003 09:45:01 -0600 " (notice
the space after the 0600), NSDate dateWithNaturalLanguageString would crash
with an "internal error". Maybe there are stray spaces or nulls or some
other invisibles affecting your situation here. m.

-- 
matt neuburg, phd = [EMAIL PROTECTED], 
A fool + a tool + an autorelease pool = cool!
One of the 2007 MacTech Top 25: 
AppleScript: the Definitive Guide - Second Edition!




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: [[NSDate alloc] initWithString] crashes with valid string

[Markus Spoettl]

On Jul 15, 2008, at 6:33 PM, Nick Zitzmann wrote:
Have you reported this to Apple through ? That is very strange behavior that obviously shouldn't be  
happening.


I will do this once I can confirm my crashes are gone. Obviously this  
takes a little extra effort because they most certainly will ignore  
the issue unless I produce a test application that recreates the crash  
reliably (which could be tricky).


Markus
--
__
Markus Spoettl



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: [[NSDate alloc] initWithString] crashes with valid string

[Nick Zitzmann]

On Jul 15, 2008, at 7:28 PM, Markus Spoettl wrote:

Thanks for the suggestion, I just tried this and now it crashes in  
initialization of NSXMLDocument (see call stack below). My  
(unfounded) suspicion was that the XMLDocument somehow was  
responsible for all the trouble.



Have you reported this to Apple through ?  
That is very strange behavior that obviously shouldn't be happening.


Nick Zitzmann


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: [[NSDate alloc] initWithString] crashes with valid string

[Markus Spoettl]

On Jul 15, 2008, at 5:00 PM, Nick Zitzmann wrote:
In addition to what everyone else has suggested, have you tried  
running your application under Guard Malloc to make sure memory is  
not being corrupted? I've caught all sorts of weird behavior in  
applications before by using Guard Malloc.



Thanks for the suggestion, I just tried this and now it crashes in  
initialization of NSXMLDocument (see call stack below). My (unfounded)  
suspicion was that the XMLDocument somehow was responsible for all the  
trouble.


The call stack tells me something strange is going on when opening the  
URL. So I changed the NSXMLDocument initialization to use a NSData  
instance that I load from the file manually and viola, the random  
crashing is gone. So apparently there is a big difference between  
loading an XMLDocument using URL and loading from NSData. Which I  
don't know, the documentation doesn't indicate special behaviour.  
Apparently it didn't like the XML URL but it does work with the data  
in it.


Thanks everyone for your suggestions, this issue gave me quite a  
number of sleepless nights.


Thanks again!

Regards
Markus


#0  0x00332556 in _mach_msg_trap at syscall_sw.h:83
#1  0x0033c8ad in mach_msg
#2  0x00360861 in vm_protect
#3  0x0009a034 in GMmalloc_zone_malloc
#4  0x940eb451 in _CFRuntimeCreateInstance
#5  0x940795a8 in __CFArrayInit
#6  0x940e0ebf in parseXMLElement
#7  0x940e27ea in parseDictTag
#8  0x940e0e95 in parseXMLElement
#9  0x940e27ea in parseDictTag
#10 0x940e0e95 in parseXMLElement
#11 0x940e0ad0 in parseXMLElement
#12 0x940e2082 in _CFPropertyListCreateFromXMLData
#13 0x940e262b in CFPropertyListCreateFromXMLData
#14 0x96e62075 in loadPolicyFromFile
#15 0x96e61faa in initializePolicy
#16 0x003588a9 in pthread_once
#17 0x96e6071e in _LSCopyDownloadAssessmentDictionaryInternal
#18 0x96e6038a in _LSCopyDownloadAssessmentDictionary
#19 0x93e3ccfd in _initDownloadAssessment
#20 0x93e50f20 in _CFURLResponseGuessMIMEType
#21 0x93e8122b in sniffForContentTypeWithData
#22 0x93e3d608 in sendDidReceiveDataCallback
#23 0x93e3ac22 in _CFURLConnectionSendCallbacks
#24 0x93e3a573 in muxerSourcePerform
#25 0x940e9615 in CFRunLoopRunSpecific
#26 0x940e9cf8 in CFRunLoopRunInMode
#27 0x93e5db42 in CFURLConnectionSendSynchronousRequest
#28	0x9545680b in +[NSURLConnection  
sendSynchronousRequest:returningResponse:error:]

#29 0x9554fe56 in -[NSXMLDocument initWithContentsOfURL:options:error:]
#30	0x0003d601 in -[RubiData(Import) importFromFile:] at RubiData 
+Import.m:257





--
__
Markus Spoettl



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: [[NSDate alloc] initWithString] crashes with valid string

[Nick Zitzmann]

On Jul 15, 2008, at 12:36 PM, Markus Spoettl wrote:


Any ideas what could be causing something like this?



In addition to what everyone else has suggested, have you tried  
running your application under Guard Malloc to make sure memory is not  
being corrupted? I've caught all sorts of weird behavior in  
applications before by using Guard Malloc.


Nick Zitzmann


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: [[NSDate alloc] initWithString] crashes with valid string

[Tony Becker]

I didn't see any code sniglet for this, but it's not something simple  
like:


[[NSDate alloc] initWithString:"..."];

vs

[[NSDate alloc] initWithString:@"..."];

i.e.: passing CString vs NSString?



On Jul 15, 2008, at 4:12 PM, Kyle Sluder wrote:


On Tue, Jul 15, 2008 at 2:36 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:

Any ideas what could be causing something like this?


Doesn't look like it's your fault, unless for some reason the string
is being dealloc'd under the call stack's feet -- make sure that the
call stack eventually winds up in your code; if it doesn't, you've hit
the top of the runloop and the string has probably been released by an
autorelease pool.  After confirming this, file a bug at
http://bugreport.apple.com, as this is a pretty serious issue.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/aebecker%40mac.com

This email sent to [EMAIL PROTECTED]


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: [[NSDate alloc] initWithString] crashes with valid string

[Andy Lee]

On Jul 15, 2008, at 2:36 PM, Markus Spoettl wrote:
This specific crash happened with the string: "2008-05-09 19:47:47  
+", which seems perfectly valid input for NSDate -initWithString:.


Works for me:

- (void)awakeFromNib
{
NSDate *date = [[NSDate alloc] initWithString:@"2008-05-09  
19:47:47 +"];

NSLog(@"date is %@", date);
}

--Andy

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: [[NSDate alloc] initWithString] crashes with valid string

[Kyle Sluder]

On Tue, Jul 15, 2008 at 2:36 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:
> Any ideas what could be causing something like this?

Doesn't look like it's your fault, unless for some reason the string
is being dealloc'd under the call stack's feet -- make sure that the
call stack eventually winds up in your code; if it doesn't, you've hit
the top of the runloop and the string has probably been released by an
autorelease pool.  After confirming this, file a bug at
http://bugreport.apple.com, as this is a pretty serious issue.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

[[NSDate alloc] initWithString] crashes with valid string

[Markus Spoettl]

Hi List,

  I've a problem I am failing to track down (let alone understand)  
for a couple of weeks now. My application imports XML files that  
contain - amongst other things - dates. Once in a while, the string to  
date conversion causes a crash (EXC_BAD_ACCESS):


#0  0x90b1da14 in ures_getIntVector
#1  0x90b20eb0 in icu::Calendar::setWeekCountData
#2  0x90b1f463 in icu::GregorianCalendar::GregorianCalendar
#3  0x90b1ee16 in icu::Calendar::createInstance
#4  0x90b1c73e in ucal_open
#5  0x940a097b in __CFCalendarCreateUCalendar
#6  0x940a0a22 in __CFCalendarSetupCal
#7  0x940a15d7 in _CFCalendarComposeAbsoluteTimeV
#8  0x95428cbc in -[NSCFCalendar dateFromComponents:]
#9  0x9542879b in -[NSDate(NSDate) initWithString:]

This specific crash happened with the string: "2008-05-09 19:47:47  
+", which seems perfectly valid input for NSDate -initWithString:.


The string appears to be a valid object - if it is any indication (I  
don't know if it is) the debugger tells me the string value on the  
call stack just fine.


Any ideas what could be causing something like this?

Thanks!
Markus
--
__
Markus Spoettl



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]