Re: Crashes inside CFStringDeallocate

One idea is to force an additional release. If the error is the same, then this is what is causing it. > On Jun 11, 2018, at 1:31 AM, Alastair Houghton > wrote: > > On 10 Jun 2018, at 19:14, Dave wrote: >> >> Override the dealloc method and log when its called - its probably being >>

Re: Crashes inside CFStringDeallocate

On 10 Jun 2018, at 19:14, Dave wrote: > > Override the dealloc method and log when its called - its probably being > over-released! That isn’t quite as simple as it sounds, because this is NSString we’re talking about, which is a class cluster. Most actual NSString instances are really

Re: Crashes inside CFStringDeallocate

Override the dealloc method and log when its called - its probably being over-released! All the Best Dave > On 8 Jun 2018, at 01:23, Jens Alfke wrote: > > > >> On May 29, 2018, at 7:39 AM, Alastair Houghton >> wrote: >> >> There’s clearly some kind of bug in your code, but it doesn’t

Re: Crashes inside CFStringDeallocate

> On May 29, 2018, at 7:39 AM, Alastair Houghton > wrote: > > There’s clearly some kind of bug in your code, but it doesn’t appear to be in > the lines you showed us. If I had to guess, I’d say you’ve over-released > your NSString somehow (leading to an attempted double free of the

Re: Crashes inside CFStringDeallocate

On 25 May 2018, at 22:18, Vojtěch Meluzín 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

Re: Crashes inside CFStringDeallocate

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

Re: Crashes inside CFStringDeallocate

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

Re: Crashes inside CFStringDeallocate

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

Re: Crashes inside CFStringDeallocate

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

Re: Crashes inside CFStringDeallocate

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 : > On May

Re: Crashes inside CFStringDeallocate

On May 25, 2018, at 5:44 AM, Vojtěch Meluzín 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

Crashes inside CFStringDeallocate

Hi, 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? I have tested 4 computers, with like 6 different OSX versions, always works here, yet there are machines where this happens