Discussion:
Crashes inside CFStringDeallocate
(too old to reply)
Vojtěch Meluzín
2018-05-25 10:44:07 UTC
Permalink
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: 0x0000000000000000,
0x0000000000000000Application Specific Information:abort() called*** error
for object 0x61800167df40: Freeing already free'd pointerThread 0 Crashed::
Dispatch queue: com.apple.main-thread0 libsystem_kernel.dylib
0x00007fff8d6b4286 __pthread_kill + 101 libsystem_c.dylib
0x00007fff875699a3 abort + 1292 libsystem_malloc.dylib
0x00007fff8391df4f nanozone_error + 5243 com.apple.CoreFoundation
0x00007fff8abb3606 __CFStringDeallocate + 2144 com.apple.CoreFoundation
0x00007fff8abb0c9e CFRelease + 5265 com.apple.logic10
0x000000010f6ea9bb std::__1::vector<TOSCService,
std::__1::allocator<TOSCService> >::vector(std::__1::vector<TOSCService,
std::__1::allocator<TOSCService> > const&) + 804116 com.apple.logic10
0x000000010f6eaff3 std::__1::vector<TOSCService,
std::__1::allocator<TOSCService> >::vector(std::__1::vector<TOSCService,
std::__1::allocator<TOSCService> > const&) + 820037 com.apple.logic10
0x000000010f760fda void std::__1::vector<CTRow,
std::__1::allocator<CTRow> >::__push_back_slow_path<CTRow>(CTRow&&) +
3622988 com.apple.logic10 0x000000010f725dc0 void
std::__1::vector<CTRow, std::__1::allocator<CTRow>
::__push_back_slow_path<CTRow>(CTRow&&) + 1200969 com.apple.AppKit
0x00007fff88412e89 -[NSApplication runModalForWindow:] + 138*

Cheers!
Vojtech
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive.net
Ken Thomases
2018-05-25 14:26:13 UTC
Permalink
Post by Vojtěch Meluzín
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?
Post by Vojtěch Meluzín
[…] NSStrings, which are
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-***@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/gegs%40ml-in.narkive.net

This em
Vojtěch Meluzín
2018-05-25 20:49:39 UTC
Permalink
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
Post by Ken Thomases
Post by Vojtěch Meluzín
I have received a few cases like the trace below - it always happens in
OSX
Post by Vojtěch Meluzín
10.10 and runModalForWindow and crashes in CFStringDeallocate. Any ideas
what that could be?
Have you run your app with the Zombies instrument?
Post by Vojtěch Meluzín
[…] NSStrings, which are
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-***@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/gegs%40ml-in.narkive.net

This email sent to geg
Vojtěch Meluzín
2018-05-25 21:18:27 UTC
Permalink
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
Post by 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
Post by Ken Thomases
Post by Vojtěch Meluzín
I have received a few cases like the trace below - it always happens in
OSX
Post by Vojtěch Meluzín
10.10 and runModalForWindow and crashes in CFStringDeallocate. Any ideas
what that could be?
Have you run your app with the Zombies instrument?
Post by Vojtěch Meluzín
[…] NSStrings, which are
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-***@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/gegs%40ml-in.narkive.net

This email sent
Jack Brindle
2018-05-25 22:30:51 UTC
Permalink
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
Post by 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
Post by 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
Post by Ken Thomases
Post by Vojtěch Meluzín
I have received a few cases like the trace below - it always happens in
OSX
Post by Vojtěch Meluzín
10.10 and runModalForWindow and crashes in CFStringDeallocate. Any ideas
what that could be?
Have you run your app with the Zombies instrument?
Post by Vojtěch Meluzín
[…] NSStrings, which are
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
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email
Vojtěch Meluzín
2018-05-26 10:18:18 UTC
Permalink
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
Post by 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
Post by 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
Post by Vojtěch Meluzín
Thanks for the reply Ken. I don't really know what Zombies instrument
is,
Post by Vojtěch Meluzín
Post by Vojtěch Meluzín
I'll check. The GetLength returns the number of UTF-16 characters (hence
half of the buffer length), not including zero terminator.
Cheers!
Vojtech
On May 25, 2018, at 5:44 AM, Vojtěch Meluzín <
Post by Vojtěch Meluzín
I have received a few cases like the trace below - it always happens
in
Post by Vojtěch Meluzín
Post by Vojtěch Meluzín
OSX
Post by Vojtěch Meluzín
10.10 and runModalForWindow and crashes in CFStringDeallocate. Any
ideas
Post by Vojtěch Meluzín
Post by Vojtěch Meluzín
Post by Vojtěch Meluzín
what that could be?
Have you run your app with the Zombies instrument?
Post by Vojtěch Meluzín
[…] NSStrings, which are
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
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This email sent to ***@ml-in.narkive
Gary L. Wade
2018-05-26 18:40:00 UTC
Permalink
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/>
Post by 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
Post by 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
Post by 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
Post by Vojtěch Meluzín
Thanks for the reply Ken. I don't really know what Zombies instrument
is,
Post by Vojtěch Meluzín
Post by Vojtěch Meluzín
I'll check. The GetLength returns the number of UTF-16 characters (hence
half of the buffer length), not including zero terminator.
Cheers!
Vojtech
On May 25, 2018, at 5:44 AM, Vojtěch Meluzín <
Post by Vojtěch Meluzín
I have received a few cases like the trace below - it always happens
in
Post by Vojtěch Meluzín
Post by Vojtěch Meluzín
OSX
Post by Vojtěch Meluzín
10.10 and runModalForWindow and crashes in CFStringDeallocate. Any
ideas
Post by Vojtěch Meluzín
Post by Vojtěch Meluzín
Post by Vojtěch Meluzín
what that could be?
Have you run your app with the Zombies instrument?
Post by Vojtěch Meluzín
[…] NSStrings, which are
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-***@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/gegs%40ml-in.narkive.net

This email sent to gegs
Alastair Houghton
2018-05-29 14:39:13 UTC
Permalink
Post by 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.
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-***@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/gegs%40ml-in.
Jens Alfke
2018-06-07 23:23:51 UTC
Permalink
Post by Alastair Houghton
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-***@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/gegs%40ml-in.narkive.
Dave
2018-06-10 18:14:08 UTC
Permalink
Override the dealloc method and log when its called - its probably being over-released!


All the Best
Dave
Post by Jens Alfke
Post by Alastair Houghton
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
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/dave%40looktowindward.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net

This ema
Alastair Houghton
2018-06-11 06:31:54 UTC
Permalink
Post by Dave
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-***@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/gegs%40ml-in.na
Alex Zavatone
2018-06-11 22:15:10 UTC
Permalink
One idea is to force an additional release. If the error is the same, then this is what is causing it.
Post by Alastair Houghton
Post by Dave
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
_______________________________________________
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@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/gegs%40ml-in.narkive.net
Loading...