Compiling asterisk against uclibc-0.9.29
Ming-Ching Tiew
mingching.tiew at redtone.com
Tue Oct 21 03:25:37 UTC 2008
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 ?
More information about the uClibc
mailing list