Re: Crashes inside CFStringDeallocate

2018-06-11 Thread Alex Zavatone 
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 
>> 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 NSCFString, though there’s nothing stopping other things from cropping 
> up.  To make this work, you’d have to change the class of the string object 
> for your own subclass (quite possibly using object_setClass(), because 
> there’s a good chance the string object either didn’t come from your code).
> 
> It’s probably better to use the built-in debugging features (zombies and the 
> various memory debugging tools in Instruments, not to mention the debugging 
> features in malloc). 
> 
> Kind regards,
> 
> Alastair.
> 
> --
> http://alastairs-place.net
> 
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashes inside CFStringDeallocate

2018-06-11 Thread Alastair Houghton 
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 
NSCFString, though there’s nothing stopping other things from cropping up.  To 
make this work, you’d have to change the class of the string object for your 
own subclass (quite possibly using object_setClass(), because there’s a good 
chance the string object either didn’t come from your code).

It’s probably better to use the built-in debugging features (zombies and the 
various memory debugging tools in Instruments, not to mention the debugging 
features in malloc). 

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashes inside CFStringDeallocate

2018-06-10 Thread Dave 
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 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 underlying 
>> storage);
> 
> ^This. The crash log clearly says "Freeing already free'd pointer”. If I had 
> to guess, I’d say that your code is failing to create an NSString from UTF-16 
> data (for the reasons already described in this thread), and the 
> failure-handling code path of your code ends up double-releasing a string. 
> (Which should be impossible with ARC alone; are you calling CFString APIs 
> anywhere?)
> 
> —Jens
> 
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/dave%40looktowindward.com
> 
> This email sent to d...@looktowindward.com

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashes inside CFStringDeallocate

2018-06-07 Thread Jens Alfke 


> 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 underlying 
> storage);

^This. The crash log clearly says "Freeing already free'd pointer”. If I had to 
guess, I’d say that your code is failing to create an NSString from UTF-16 data 
(for the reasons already described in this thread), and the failure-handling 
code path of your code ends up double-releasing a string. (Which should be 
impossible with ARC alone; are you calling CFString APIs anywhere?)

—Jens

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashes inside CFStringDeallocate

2018-05-29 Thread Alastair Houghton 
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 big deal.

That’s extremely unlikely.  Plenty of code constructs NSStrings from UTF-16 
data, and the rest of us aren’t seeing crashes in CFStringDeallocate.

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 underlying 
storage); turning on Zombies in your Xcode build scheme is not a bad idea, and 
turning on the malloc debugging features (MallocStackLogging and 
MallocStackLoggingNoCompact might be helpful) might be a good fallback option 
if enabling zombies doesn’t show you precisely where things are going wrong.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashes inside CFStringDeallocate

2018-05-26 Thread Gary L. Wade 
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 


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/ 

> On May 26, 2018, at 3:18 AM, Vojtěch Meluzín  
> 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 :
> 
>> 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 
>> 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 :
>>> 
 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 25, 2018, at 5:44 AM, Vojtěch Meluzín <
>> meldaproduct...@gmail.com>
> 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 (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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashes inside CFStringDeallocate

2018-05-26 Thread Vojtěch Meluzín 
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 :

> 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 
> 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 :
> >
> >> 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 25, 2018, at 5:44 AM, Vojtěch Meluzín <
> meldaproduct...@gmail.com>
> >>> 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 (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:
> > https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> >
> > This email sent to jackbrin...@me.com
>
>
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashes inside CFStringDeallocate

2018-05-25 Thread Jack Brindle 
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  
> 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 :
> 
>> 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 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 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 (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:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
> 
> This email sent to jackbrin...@me.com

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashes inside CFStringDeallocate

2018-05-25 Thread Vojtěch Meluzín 
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 :

> 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 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 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 (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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashes inside CFStringDeallocate

2018-05-25 Thread Vojtěch Meluzín 
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 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 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 (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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Crashes inside CFStringDeallocate

2018-05-25 Thread Ken Thomases 
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 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 (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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Crashes inside CFStringDeallocate

2018-05-25 Thread Vojtěch Meluzín 
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
apparently, somewhere out there :). Moreover all the Cocoa calls here are
actually just wrapped in our crossplatform library, and there's not much
going on, that makes this especially surprising. 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()];

The crash log excerpt:




















*Crashed Thread:  0  Dispatch queue: com.apple.main-threadException Type:
 EXC_CRASH (SIGABRT)Exception Codes: 0x,
0xApplication Specific Information:abort() called*** error
for object 0x61800167df40: Freeing already free'd pointerThread 0 Crashed::
Dispatch queue: com.apple.main-thread0   libsystem_kernel.dylib
0x7fff8d6b4286 __pthread_kill + 101   libsystem_c.dylib
 0x7fff875699a3 abort + 1292   libsystem_malloc.dylib
0x7fff8391df4f nanozone_error + 5243   com.apple.CoreFoundation
0x7fff8abb3606 __CFStringDeallocate + 2144   com.apple.CoreFoundation
0x7fff8abb0c9e CFRelease + 5265   com.apple.logic10
 0x00010f6ea9bb std::__1::vector::vector(std::__1::vector const&) + 804116   com.apple.logic10
 0x00010f6eaff3 std::__1::vector::vector(std::__1::vector const&) + 820037   com.apple.logic10
 0x00010f760fda void std::__1::vector::__push_back_slow_path(CTRow&&) +
3622988   com.apple.logic10  0x00010f725dc0 void
std::__1::vector::__push_back_slow_path(CTRow&&) + 1200969   com.apple.AppKit
0x7fff88412e89 -[NSApplication runModalForWindow:] + 138*

Cheers!
Vojtech
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com