Re: [lwip-devel] Sockets: select_waiting overflow

[Joan Lledó]

2017-07-04 16:10 GMT+02:00 Stian Skjelstad <address@hidden>:
>> >  What is your application design since you happen to hit this assertion?
>> > Are
>> > you not properly keeping track of your file descriptors and sometimes
>> > ends
>> > up with the a "zombie" file descriptor in an another thread, or some
>> > kind of
>> > memory-corruptions?
>> >
>>
>> In my implementation, if you call select() to read from a fd_set with,
>> say, three sockets, then lwip_select() is called three times in three
>> different threads, one for each socket. When there's an event in one
>> of them, the other two threads keep waiting, if timeout is null, then
>> those two threads never return. This leads sshd to create hundreds of
>> threads in a matter of seconds.
>
>
> Hundreds of threads will cause the byte-overflow mentioned by Simon.
>
> So, in your example you have three threads, each thread has a different
> file-descriptor they are responsible for, which they set in their own fd_set
> and call select().

Yes, exactly.

> And then two of the threads get stuck. I will guess that they are stuck in
> the semaphore sleep (I might be wrong, it often happens). I would checked
> the implementation of the semaphores and thread scheduling/waking up. Are
> you able to easily debug the sleeping threads?

Yes, I've got the core dump and all the threads are stuck in
pthread_cond_wait(), called by sys_arch_sem_wait(). My problem is the
threads are not being cancelled, but that's not handled by LwIP.

>
> Stian Skjelstad
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-devel
>