Possible bugs appearing on Mac OS X, but not on Linux

[Jacques-Olivier Haché]

Hi everyone,

This thread is related to a previous thread of mine: https://groups.google.com/forum/#!topic/discuss-webrtc/m1y8ZawuqC4.

I'm using the latest version of webrtc as a basis for my C++ app. Some issues have appear while calling some webrtc native functions.To make it easier for you to understand the issue, I created a small program that re-creates the bugs on every run. The code is in the archive attached to this mail.

I was able to trigger this bug on this configuration:

- MacBook Air 2012

- Mac OS X 10.9.2

- Compiling either with Ninja, or with clang inside XCode 5.0.2

It's interesting that there program works just fine on an Ubuntu 13.10, custom hardware, Ninja compiler configuration; I did not get to try on Windows yet.

How to use the program:

- Download the latest version of webrtc and the archived attached to this email

- Extract the archive and copy/paste the folder BugExp and the file bugExp.gyp in the trunk/talk directory

- Add this target to you all.gyp: 'talk/bugExp.gyp:*',

- runhooks

- compile: ninja -C out/Debug bugExp (alternatively, you can use Xcode/clang

- run the executable: ./out/Debug/bugExp

- There are some std::cin in the program to let you time to see what's happening. Just follow the instructions from the program.

What the program should do:
- Create a PC factory
- List the video devices
- Create a MediaStream (called localMediaStream) with the first video capture device found
- Create a peerConnection (I have a wrapper around it that handles the observers)
- Add the MediaStream into the peerConnection
- Render the stream in a new window
- Create the offer for this PC


Issue 1:

The program basically gets stuck in the creation of the videoSource.
For more precision, I went down with the debugger and the program is waiting forever in thread.cc on this line:

void Thread::Send(MessageHandler *phandler, uint32 id, MessageData *pdata) {
 ...
 current_thread->socketserver()->Wait(kForever, false);
 ...
}

In my main program I was able to bypass this lock by launching my GUM in a new boost::thread, but it didn't do the trick here, I'm not sure why (I let the code in comments in case somebody would like to try it).


Issue 2:
Even when GUM works in my main program, calling createOffer on the PeerConnection containing the MediaStream causes its rendering to stop. I actually don't believe the problem comes from the renderer. I believe it must be in the stream or the source, but I can't get a proper idea as simply entering the debugger causes the renderer to freeze until the program resumes (as expected).


Questions:
- What are the differences that prevent my program to run properly on Mac not on Linux?

- What is expected of me regarding threading? Am I supposed to work on the main thread? Create different threads? If yes in which case?

- Do I miss some pre-proc definition, or initialization somewhere?

- The rendering freezing every time I enter the debugger is going to be a big issue all along the development of my app. Is there a way to bypass this freezing effect? How do you guys handle it?

- Should I open an issue?

Thanks in advance.

[Jacques-Olivier Haché]

I continued my research regarding these problems and I have a couple of updates on issue 2:

- I realized the rendering didn't freeze exactly on createOffer, but on setLocalDescription, which I trigger in the handler of createOffer success.

- On the mac device, I tried creating a copy of that sessionDescription, but had an error in the first place. I fixed this error by renaming my videoTrack by removing non standard english letters, such a "é", or "è" (the mac is french). However, the rendering still freezes on setLocalDescription;

I also updated my example which now goes all the way to sending the answer, sending the iceCandidates much more properly. I also corrected some mistakes of my own. The new version is attached to this email.

Did anybody have a chance to take a look at the issue yet?

[Guillaume Egles]

Hello (Bonjour),

I think I am running into a very similar issue on Mac (Yosemite). I haven't yet been able to test on a different platform. I posted issue4280 but then also realized issue3989 could also be related.

Did you ever figure yours out? Any clue or pointer much appreciated.

I tried to compile your example code, but I think the webrtc codebase as changed quite a bit since.

Thanks. Merci. Guillaume.

[Jacques-Olivier Haché]

Hi,

Yes, this is almost a year old, and libWebRTC evolves daily...

I did manage to sort it out; From the top of my head:

- libWebRTC will send event/messages/native called to the main thread of you application.

- If your main thread is already doing something, you might end up in a dead lock. 

Say you make a call to libWebRTC on the main thread, and this call relies on some on some event to be handled on the main thread, then you are deadlocked.

- The solution I found was to create custom thread when facing this issue. I personally use boost::threads, but I'm sure any other kind of thread would work just as well.

On every new thread, you should start by calling :

rtc::ThreadManager::Instance()->SetCurrentThread(

   rtc::ThreadManager::Instance()->WrapCurrentThread()

 );

Which basically declares your thread to libWebRTC.

I wish there was a way to tell libWebRTC not to do those messages/calls on the main thread but on a custom thread, but I didn't find one yet.

If you do find one, I would appreciate you come back to me :)

Hope this helps;

J-O

[you...@gmail.com]

This might also be related to https://code.google.com/p/webrtc/issues/detail?id=3547