Extremely strange NSString bug

[Elise Monaghan]

The webrtc objective c sdk includes an extension to the NSString functionality, namely a helper method that converts an NSString to an std::string:

https://chromium.googlesource.com/external/webrtc/+/branch-heads/4389/sdk/objc/helpers/NSString+StdString.mm#20

For some reason, when running my application outside of XCode, the above function fails to convert strings and returns them as "!". When running my application inside of XCode, I don't encounter this issue. How is this possible?

The specific point of failure comes when the Ice Servers are being parsed during the Peer Connection initialization, here:

https://chromium.googlesource.com/external/webrtc/+/master/pc/ice_server_parsing.cc#292

url.stdString is incorrectly returned as "!" :

https://chromium.googlesource.com/external/webrtc/+/branch-heads/4389/sdk/objc/api/peerconnection/RTCIceServer.mm#139

I can confirm that, if I replace the string conversion with an alternative such as here:

https://stackoverflow.com/questions/8001677/how-do-i-convert-a-nsstring-into-a-stdstring/21855876#21855876

Then I don't hit the error anymore. 

Any ideas? I use a debug version of the webrtc lib to print my strings at every point, and I can confirm they exist at every single point, right up to the point where they hit the conversion to std::string, which returns empty strings....

Again, this only reproduces when I run my application file directly; I have no errors when building and running inside of XCode.

[medusade]

...sounds like a side effect that appears out of XCode due to different memory configuration. usually occurs with strings that have dangling pointers or problems with '\0' termination...

[Elise Monaghan]

Can you elaborate on what you mean by 'different memory configuration' ?

Also the strings are members of my class, and there is no conversion funkiness going on i.e I am literally initializing the string in the most uncontroversial way possible, such as 

NSString *server = @"testserver.com";

So I really can't see how they can just become nil outside of XCode =\

[Medusa Development]

Can you elaborate on what you mean by 'different memory configuration' ?

-- running in xcode as debug has a different memory layout than running out which may hide side effects caused by threading (race conditions).

try writing a simple program that just tests the NSString without any threading.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8dce8891-6059-45d0-b6a2-d8e5604843a3n%40googlegroups.com.

[Elise Monaghan]

Figured out the cause of the problem, but not where it's happening. Renaming the webrtc functions in NSString+StdString.mm solved the issue. Seems that, somewhere in my application, is either a) another library that also implements a category for NSString w/ the same function name, or b) another implementation of WebRTC internally.

Basically if more than one category extends the same class w/ the same function name, you get a name clash, and the behavior is undefined. Very strange.

[Josh Lytle]

I ran into the exact same bug. Here's what I discovered, at least in my case. My hypothesis was that it was being caused by a name conflict. Objective-C says that if two categories for the same class define a method with the same name, the behavior is undefined. Well, my guess is some other widely used framework or library is also defining "stdString" or one of the other NSString methods WebRTC is defining, and this is causing a clash.

I confirmed this, in my project, by modifying WebRTC's source. I renamed each of the NSString category method names by appending "WebRTC" to the end (e.g. stdStringWebRTC instead of stdString) and then globally replaced all instances of them in the objc files in WebRTC. This fixed the problem. Maybe it will fix it for you as well. Obviously a permanent fix would be something like WebRTC updating it's code to not use a category to avoid name clashes, or renaming the methods with prefixes/suffixes to reduce the chances.

Hope this helps.

[Josh Lytle]

I actually wrote my reply on July 26, but moderation prevented it from posting.