Re: Issue with NSDateFormatter on Windows with ICU...

[Gregory Casamento]

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 <address@hidden> 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" <address@hidden> 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 <address@hidden> 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
address@hidden
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