ErizoJs crash

[shahrukh330]

Hi,

ErizoJs crashes when more then 12 participants are in the room and someone tries to disconnect. I tried debugging on gdb and it shows segmentation fault at memcpy or sometimes at MediaSink::deliverAudioData.

I took a new checkout of licode.

I have been digging in to source and in OneToManyProcessor.cpp
` int OneToManyProcessor::deliverAudioData_(std::shared_ptr audio_packet) {
if (audio_packet->length <= 0)
return 0;

boost::unique_lock<boost::mutex> lock(monitor_mutex_);
if (subscribers.empty())
  return 0;

std::map<std::string, std::shared_ptr<MediaSink>>::iterator it;
for (it = subscribers.begin(); it != subscribers.end(); ++it) {
  (*it).second->deliverAudioData(audio_packet);
}

return 0;

}
`
shouldnt there be a nullptr check before calling deliverAudioData() like there is in deliverVideoData()?
Guys its just a wild guess didnt solve the crash though.

[jcague]

@shahrukh330 can you try with PR #804 please? I think it could solve this issue.

[shahrukh330]

@jcague Thankyou i'll try it today. I temporarily fixed it from crashing by using a dirty hack ( copying code in copying code in destructor of WebRtcConnection.cpp in close method which was empty.) Your solution looks more promising though :)

[shahrukh330]

@jcague i tried PR #804. It didnt fix the problem. it is still crashing in MediaSink::deliverAudioData and deliverVideoData. I dug around the issue during the past few days and i think the problem is that the oneToManyProcessor is closed before closing the webrtc connection which recieves data and crashes while passing it over to sink.

[jcague]

That's exactly the issue this PR aims to fix. I'll double check again if there are more ways to close it. I think the PR should fix some weird cases anyway so I'll merge it in the mean time.

[jcague]

@shahrukh330 we're still investigating this issue since we're seeing it from time to time but we can't reproduce it locally. Could you try PR #834 please?