Compiling asterisk against uclibc-0.9.29

[Ming-Ching Tiew]

Rob Landley wrote:
> 
>>> Do you have a small test case that's not part of the asterisk
>>> package but just a program we can compile and run on our own
>>> systems? 
>> 
>> I will try to write one to see if it is repeatable. I have heard
>> people having this problem with 'dropbear' but I have not seen it
>> myself. 
> 
> It sounds serious and definitely in need of fixing.  I just can't do
> anything about it yet because I haven't reproduced it.
> 

Wow as I get into it, it's more complicated than I thought :-

1. I could not reproduce it using the simpliest case I could
    imagine. 

2. I could not fix the problem by applying sleep() to uclibc.

3. However I could workaround the problem by taking 
    uclibc daemon() code, put it into asterisk, call it 
    my_daemon() and call that function in asterisk code.

4. As I put in daemon() code into asterisk, I also put
    some sleep() there. This change makes works. As 
    it turns out, sleep() is actually uncessary. This change
    works was due to me taking the daemon() code and
    compiling it into asterisk.

5. In the bugged case, the daemonized process did not 
    actually die, it lingers around ( it's one of the 3 processes ).
    Further down in the source, it calls ast_makesocket().
    But in ast_makesocket() it was stuck in pthread_create() 
    and never return ( this accounts for the additional 2 process 
    created ).

    Strange thing is that if I don't call daemon() or if I compile
    daemon() into asterisk source, then ast_makesocket()
    ( and hence pthread_create() ) will not block.

Have I confused you guys yet ?