[asterisk-dev] Deadlock in pthread_exit due to lazy binding with libgcc

[Yousf Ateya]

Here is the difference in loading time (on Intel i5 machine):

The default (with lazy linking): 1.422 seconds
With non-lazy linking: 1.852 seconds

On Fri, Jul 17, 2015 at 6:04 PM, Mark Michelson <mmichelson at digium.com>
wrote:

>  On 07/15/2015 08:41 AM, Yousf Ateya wrote:
>
>  Dear,
>
>  I started to see a  strange deadlock in some asterisk nodes. For every
> call, when calling pthread_exit from pbx_thread, the caller thread is stuck
> inside pthread_exit.
>
>  After a while, there will be tens-of-thousands of threads having the
> same backtrace. After some googling, I found this happens because of the
> default lazy linking of gcc linker.
>
>  Related issue of stackoverflow:
> http://stackoverflow.com/questions/11954527/dlopen-malloc-deadlock
>
>  Tried to recompile asterisk using:
> export LDFLAGS=-Wl,-z,now
>  ./configure && make && make install
>
>  and this deadlock problem didn't happen again; the problem cause is lazy
> binding with libgcc.
>
>  Shall we add this option by default or add it in menuselect?
>
>
> <snip>
>
>
>  --
>   Yousf Ateya,
>  StarkBits
> www.starkbits.com
>
>
> Thanks for this report. Based solely on the man page for ld(1), it sounds
> like load-time binding would, at most, cause module loading to take longer.
> Are there any other potential issues to making this change?
>
> Mark Michelson
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
Yousf Ateya,
StarkBits
www.starkbits.com

-- 


This e-mail message is intended only for the use of the intended recipient(s).
The information contained therein may be confidential or privileged,
and its disclosure or reproduction is strictly prohibited.
If you are not the intended recipient, please return it immediately to its sender 
at the above address and destroy it. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150719/aef260bb/attachment.html>