The call is occurring on the following line in that file:
(gdb) list 981
976
977 tzIDLength = [[internal->_tz name] length];
978 tzID = NSZoneMalloc ([self zone], sizeof(UChar) * tzIDLength);
979 [[internal->_tz name] getCharacters: tzID range: NSMakeRange (0,
tzIDL
ength)];
980
981 internal->_formatter = udat_open
(NSToUDateFormatStyle(internal->_time
Style),
982
NSToUDateFormatStyle(internal->_dateStyle),
983 [[internal->_locale localeIdentifier]
UTF8Stri
ng],
984 tzID,
985 tzIDLength,
(gdb)
986 NULL,
987 0,
988 &err);
989 if (U_FAILURE(err))
990 internal->_formatter = NULL;
991
992 NSZoneFree ([self zone], tzID);
993 #else
994 return;
995 #endif
(gdb)
Here is what is being sent....
(gdb) p *(NSDateFormatterInternal *)_internal
$3 = {{isa = 0x6702f740}, _behavior = 0, _locale = 0x41f9a28,
_tz = 0x278ce08, _timeStyle = 0, _dateStyle = 0, _formatter = 0x0}
(gdb) p NSToUDateFormatStyle(0)
$4 = -1
(gdb) po ((NSDateFormatterInternal *)_internal)->_locale
en_US
(gdb) p tzID
$6 = (
UChar *) 0x4202b80 "E\000a\000s\000t\000e\000r\000n\000
\000S\000t\000a\000n
\000d\000a\000r"
(gdb) p tzIDLength
$7 = 21
(gdb)
Later, GC
On Tue, Nov 27, 2012 at 12:35 PM, Stefan Bidi <[email protected]> wrote:
> That would not be a bad idea. However, if ICU can't open a simple
> formatter there is something serious wrong. The new functionality depends
> on a good formatter.
>
> Could you add a break point on-_resetUDateFormat and check what is being
> feed into the udat_open function?
> On Nov 27, 2012 11:25 AM, "Gregory Casamento" <[email protected]>
> wrote:
>
>> Should I put in error handling for this case and issue a warning if this
>> happens when using ICU? It seems wrong not to check for an error
>> condition in this case.
>>
>> I'd like to find out why this is happening in the first place.
>>
>> I found it while testing the new Cairo changes, but it doesn't seem like
>> this would be backend specific. I tested with both backends just to be
>> sure and I get the same results.
>>
>> GC
>>
>>
>> On Tue, Nov 27, 2012 at 9:47 AM, Richard Frith-Macdonald <
>> [email protected]> wrote:
>>
>>>
>>> On 27 Nov 2012, at 13:57, Gregory Casamento wrote:
>>>
>>> > Hey guys,
>>> >
>>> > I am having a problem starting up Gorm on Windows. I have traced it
>>> to this section of code in NSDateFormatter...
>>> >
>>> > 125
>>> > 126 length = udat_toPattern (internal->_formatter, 0, NULL, 0,
>>> &err);
>>> > 127 value = NSZoneMalloc (z, sizeof(unichar) * length);
>>> > 128 err = U_ZERO_ERROR;
>>> > 129 udat_toPattern (internal->_formatter, 0, value, length,
>>> &err);
>>> >
>>> > The issue is that length is coming back as -1, which, when the
>>> NSZoneMalloc tries to allocate ends up trying to allocate all available
>>> memory since the value is interpreted as unsigned.
>>> >
>>> > The only reason Gorm gets this issue and the other apps I tested don't
>>> is due to the fact that none of the others attempt to use NSDateFormatter.
>>>
>>> I know nothing about this code directly, but I had a little look anyway:
>>>
>>> All the documentation I can find online says that udat_toPattern()
>>> should return a length ... so this problem shouldn't happen.
>>> But I guess it's returning -1 as an error condition of some sort ...
>>> just looking at it I'd guess the problem must be incorrect initialisation
>>> of internal->_formatter.
>>> So I'd recommend you try looking for a problem earlier on, to do wioth
>>> initialisation of the formatter.
>>
>>
>>
>>
>> --
>> Gregory Casamento
>> Open Logic Corporation, Principal Consultant
>> yahoo/skype: greg_casamento, aol: gjcasa
>> (240)274-9630 (Cell)
>> http://www.gnustep.org
>> http://heronsperch.blogspot.com
>>
>> _______________________________________________
>> Gnustep-dev mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>
>>
--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
