Creation of pipes that are never closed by webrtc2sip - eventually resulting in "too many open files errors"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I'm using a setup of 'SIPML5 Call.htm'(Chrome, Windows) +
Webrtc2Sip +
Asterisk 1.2

Webrtc2Sip and Asterisk are installed on the same machine and OS (Fedora)
Both webrtc2sip and doubango were checked out in March 2014 - Doubango 2.0.

2. Make some calls from any SIP-clients registered in Asterisk, where at least 
one call-client is using webrtc2sip both as a proxy and a media-gateway 
(web-breaker, through SIPml5).

3.
What is the expected output? What do you see instead?

Nothing bad happens from user-perspective for the first N calls, but eventually 
webrtc2sip crashes, probably because the open files associated with webrtc2sip 
seems to grow without bounds:

####BEFORE CALL-X-Y
[root@pbxdev webrtc2sip]# lsof | grep web | grep pipe | wc -l && lsof | grep 
web | wc -l
559
622
####DURING-CALL-X-Y WHEN 2-WAY-MEDIA IS ESTABLISHED
[root@pbxdev webrtc2sip]# lsof | grep web | grep pipe | wc -l && lsof | grep 
web | wc -l && date
563
630
####AFTER CALL-X-Y HAS BEEN TERMINATED:
[root@pbxdev webrtc2sip]# lsof | grep web | grep pipe | wc -l && lsof | grep 
web | wc -l
561
624

so 2 pipes (590w, 587w) are created but never destroyed.

After lots of calls I get a crash, probably Segmentation-fault because of too 
many open files?

What version of the product are you using? On what operating system?
see above,
Please provide any additional information below:

I can post any config/source/logfiles if requested, but I don't know what info 
is useful. I have made some minor local changes to the doubango source code 
such as disabling the socket-option: SO_REUSEADDR when creating RTP-ports 
(ice-candidate-offers), because that was causing me problems during testing, 
but I don't know if that change causes the "too many open pipes", so i want to 
know if you have ever observed this problem and when these pipes should be 
destroyed?

Original issue reported on code.google.com by StefanEn...@gmail.com on 26 May 2014 at 2:05

[GoogleCodeExporter]

Update: I reverted the small changes I had tested but I had the same problem 
with the open files (pipes)... So I tested something new:
In file,
/doubango/tinyNET/src/tnet_transport_poll.c
In function,
int tnet_transport_unprepare(tnet_transport_t *transport)
Added:
        if (0==close(context->pipeW)){
           TSK_DEBUG_INFO("closed hard %d",context->pipeW);
        };
Just Before:         
        /* reset both R and W sides */
        context->pipeR = 0;
        context->pipeW = 0;
Which seemed to solve the problem, but I am _not_ a C-programmer so I don't 
know if this hack is bad?

Original comment by StefanEn...@gmail.com on 27 May 2014 at 8:42

[GoogleCodeExporter]

Original comment by boss...@yahoo.fr on 27 May 2014 at 10:43

• Changed state: Accepted
• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

This is a regression. Should be fixed by r1110.

Original comment by boss...@yahoo.fr on 27 May 2014 at 11:15

• Changed state: Fixed