Re: Crashes inside CFStringDeallocate
Re: Crashes inside CFStringDeallocate
- Subject: Re: Crashes inside CFStringDeallocate
- From: "Gary L. Wade" <email@hidden>
- Date: Sat, 26 May 2018 11:40:00 -0700
While your UTF-8 representation works, it would be worth it to verify your data
is correct. Whenever I have messes with Unicode, or any data for that matter
which can be external to an Xcode execution, I eyeball the actual bytes with
Hex Fiend:
https://github.com/ridiculousfish/hexfiend
<https://github.com/ridiculousfish/hexfiend>
Also, if your data is in your own container, you should be able to use Xcode’s
view memory option.
Not to say these would cause your problem, but they may help you identify the
real reason: I’d look at endian ordering, a BOM as your first character, and an
embedded 16-bit zero within the bytes, even if it’s the last character in your
array.
--
Gary L. Wade
http://www.garywade.com/ <http://www.garywade.com/>
> On May 26, 2018, at 3:18 AM, Vojtěch Meluzín <email@hidden>
> wrote:
>
> Hard to say really, but we know that it does work properly on newer OSX (so
> there is either some sort of compatibility change, classic Apple, or there
> was a bug). I believe the UTF16 implementation we are using is correct, and
> it was used in other places in the software as well, and it always worked,
> it only crashed here in the modal window thingy in specific OSX and
> specific host programs (it's an AU plugin). Anyways it seems working now,
> so we'll stick with the slower UTF8...
>
> Cheers!
> Vojtech
> www.meldaproduction.com
>
> 2018-05-26 0:30 GMT+02:00 Jack Brindle <email@hidden>:
>
>> Not necessarily. I have never seen a guarantee that the C++ string
>> functions output their data in the exact format that [NSString
>> stringWithCharacters:length:] needs as an input. As you discovered, getting
>> UTF8 from the C++ string does give you proper data for the corresponding
>> NSString creator method.
>>
>> Assuming things are compatible between C++ and Cocoa methods usually leads
>> to bug reports at the very least.
>>
>> Jack
>>
>>> On May 25, 2018, at 2:18 PM, Vojtěch Meluzín <email@hidden>
>> wrote:
>>>
>>> Ok so I got a solution - it's the utf16 indeed. When I use [NSString
>>> stringWithUTF8String] instead, it doesn't crash. Considering it does that
>>> only on 10.10 (and probably older), it seems like OSX malfunction... oh
>>> well... Fortunately no big deal.
>>>
>>> Cheers!
>>> Vojtech
>>> www.meldaproduction.com
>>>
>>> 2018-05-25 22:49 GMT+02:00 Vojtěch Meluzín <email@hidden>:
>>>
>>>> Thanks for the reply Ken. I don't really know what Zombies instrument
>> is,
>>>> I'll check. The GetLength returns the number of UTF-16 characters (hence
>>>> half of the buffer length), not including zero terminator.
>>>>
>>>> Cheers!
>>>> Vojtech
>>>>
>>>> 2018-05-25 16:26 GMT+02:00 Ken Thomases <email@hidden>:
>>>>
>>>>> On May 25, 2018, at 5:44 AM, Vojtěch Meluzín <
>> email@hidden>
>>>>> wrote:
>>>>>>
>>>>>> I have received a few cases like the trace below - it always happens
>> in
>>>>> OSX
>>>>>> 10.10 and runModalForWindow and crashes in CFStringDeallocate. Any
>> ideas
>>>>>> what that could be?
>>>>>
>>>>> Have you run your app with the Zombies instrument?
>>>>>
>>>>>> […] NSStrings, which are
>>>>>> probably the issue here are always created from our MString like this:
>>>>>>
>>>>>> const unichar *utf16 = (const unichar *)s.GetUTF16();
>>>>>> return [NSString stringWithCharacters: utf16 length: s.GetLength()];
>>>>>
>>>>> Does MString::GetLength() return the length in UTF-16 code units (as
>>>>> opposed to, say, UTF-8 code units)?
>>>>>
>>>>> Regards,
>>>>> Ken
>>>>>
>>>>>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden