Crash when closing large number of channels

[GoogleCodeExporter]

I have created a C/C++ library which does WebRTC data channels. Part of the 
tests is to open and close hundreds on channels. When closing 100+ channels 
from the browser in a quick succession, the sctp library does a double memory 
deallocation.
I have attached the stack trace.

I am using revision 9200 of the library.

Best regards,
Andrei

Original issue reported on code.google.com by [email protected] on 25 Mar 2015 at 1:12

Attachments:

• thread_1_backtrace.txt
• threads_list.txt

[GoogleCodeExporter]

Also, when application exits "cleanly" (no crash), I get this message printed:

hashdestroy: hash not empty.

Original comment by [email protected] on 25 Mar 2015 at 1:18

[GoogleCodeExporter]

Can you tell me what is freed multiple times? I need to figure out how to 
reproduce it...

Original comment by [email protected] on 25 Mar 2015 at 3:32

[GoogleCodeExporter]

Hi,

The app or the browser is successfully opening 100-200 channels. Than the 
browser closes the channels in a tight FOR loop by calling .close() on the 
channel object in JS. The app dies with that stack trace. However, is quite 
hard to reproduce, but it does happen from time to time. I will try to 
reproduce it again and also compile the usrsctp library with debug symbols, so 
we can get a stack trace with file/line information.

Another (possibly related) issue is with trying to open a channel immediately 
after a channel close was called from the app side.

Having a channel opened, I have concluded that the following sequences needs to 
be followed to be able to properly close a channel and immediately open another 
one:

Steps that should be taken by my app when channel is closed by the browser

1. App gets SCTP_STREAM_RESET_EVENT event notification with 
SCTP_STREAM_RESET_INCOMING
2. App gets SCTP_STREAM_RESET_EVENT event notification with 
SCTP_STREAM_RESET_OUTGOING
3. App calls usrsctp_setsockopt with IPPROTO_SCTP and SCTP_RESET_STREAMS having 
srs_flags set on SCTP_STREAM_RESET_INCOMING | SCTP_STREAM_RESET_OUTGOING
4. App waits for the SCTP_STREAM_RESET_EVENT events again, on the same channel
5. App gets SCTP_STREAM_RESET_EVENT event notification with 
SCTP_STREAM_RESET_OUTGOING
6. App gets SCTP_STREAM_RESET_EVENT event notification with 
SCTP_STREAM_RESET_INCOMING
7. App finally deallocates the internal structure associated with the channel 
closed and makes the slot free for another channel

Steps taken by my app when channel is closed by the app
1. App calls usrsctp_setsockopt with IPPROTO_SCTP and SCTP_RESET_STREAMS having 
srs_flags set on SCTP_STREAM_RESET_INCOMING | SCTP_STREAM_RESET_OUTGOING
2. App waits for the SCTP_STREAM_RESET_EVENT events
3. App gets SCTP_STREAM_RESET_EVENT event notification with 
SCTP_STREAM_RESET_OUTGOING
4. App gets SCTP_STREAM_RESET_EVENT event notification with 
SCTP_STREAM_RESET_INCOMING
5. App finally deallocates the internal structure associated with the channel 
closed and makes the slot free for another channel

In any of the 2 cases presented, if I try to open another channel from the app 
at any given point within that sequence, chrome browser is simply not doing 
anything (sending back the ACK) and the channel is not opened on any side, 
although the usrsctp_sendv did not failed when sending the payload described 
here:
https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-09#section-5.1
Same message sent as step 8 for the first case or as step 6 for the second case 
works as expected, and the channel is opened. This forces the app to be aware 
of any pending channels teardown (which I have fixed recently in my app)

Best regards,
Andrei

Original comment by [email protected] on 25 Mar 2015 at 5:57

[GoogleCodeExporter]

Just to be sure: First you open several channels, then you close them all 
without sending any user messages.

Original comment by [email protected] on 19 May 2015 at 7:01

• Changed state: Started