<div dir="ltr">Hi,<div><br></div><div>I've not been able to reproduce either in a simple test case yet, which would lead to the obvious conclusion that there is some fault in my application. However, from my diagnostics i can see that a) all opened socket FD's are being passed to close() and b) that close() is not returning an error. The particular case is when my application tries to connect(), which fails as the tcp port is not open.</div><div><br></div><div>The application is a reasonably complex multi task project that will have lots of threads using sockets at the same time, could that be relevant ?</div><div><br></div><div>Interestingly i've also had problems with the httpd (mongoose) server "leaking" if web pages are opened to quickly as well, i never really got to the bottom of it, i just ended up at 512 sockets and hope people dont view pages to quickly.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 5 Apr 2019 at 07:59, Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 05/04/2019 01:17, Chris Johns wrote:<br>
> On 5/4/19 4:53 am, Matthew J Fletcher wrote:<br>
>> Hi Sebastian<br>
>><br>
>> I used rtems_task_wake_after().<br>
>><br>
>><br>
>> On Thu, 4 Apr 2019, 18:22 Sebastian Huber, <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
>><br>
>>      How do you wait. Is this a busy wait?<br>
>><br>
>>      ----- Matthew J Fletcher <<a href="mailto:amimjf@gmail.com" target="_blank">amimjf@gmail.com</a> <mailto:<a href="mailto:amimjf@gmail.com" target="_blank">amimjf@gmail.com</a>>> schrieb:<br>
>>      > replying to myself.<br>
>>      ><br>
>>      > With a 1 second pause between socket() and close() and 512 sockets it will<br>
>>      > still ENOBUFS,.. without calculating it properly thats easily 10 minutes<br>
>>      > since the first socket was allocated,. that must be enough time to start<br>
>>      > freeing the socket buffers internally.<br>
>>      ><br>
>>      ><br>
>>      > On Thu, 4 Apr 2019 at 16:47, Matthew J Fletcher <<a href="mailto:amimjf@gmail.com" target="_blank">amimjf@gmail.com</a><br>
>>      <mailto:<a href="mailto:amimjf@gmail.com" target="_blank">amimjf@gmail.com</a>>> wrote:<br>
>>      ><br>
>>      > > Hi,<br>
>>      > ><br>
>>      > > I have noticed an issue with lib-bsd that the legacy stack does not have.<br>
>>      > ><br>
>>      > > If have a loop that does<br>
>>      > ><br>
>>      > > for (;;)<br>
>>      > > {<br>
>>      > >   wait(100) // milliseconds<br>
>>      > >   socket() // allocate<br>
>>      > >   close() // free<br>
>>      > > }<br>
> Are you able to make a small stand alone test?<br>
<br>
Yes, a self contained test case would be helpful. I cannot reproduce the <br>
issue with the modified test case in attached patch for libbsd.<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br></div>