I got it, I am using version 1.2.0, Next I will switch to the latest version.




------------------ 原始邮件 ------------------
发件人:                                                                                                                        "musl"                                                                                    <dalias@libc.org&gt;;
发送时间:&nbsp;2023年2月14日(星期二) 晚上9:44
收件人:&nbsp;"兔子猪"<3264430019@qq.com&gt;;
抄送:&nbsp;"musl"<musl@lists.openwall.com&gt;;
主题:&nbsp;Re: [musl][PATCH]fix tsd's issue



On Tue, Feb 14, 2023 at 07:05:15AM -0500, Rich Felker wrote:
&gt; On Tue, Feb 14, 2023 at 03:25:23PM +0800, 兔子猪 wrote:
&gt; &gt; Currently, I am trying to port jemalloc to musl, I have found a issue "the return value of pthread_getspecific is not correct". The reasons are as follows:
&gt; &gt; 1, Jemalloc uses pthread_key_t to implement cache feature, if codes call malloc, pthread_create_key will called and tsd will be initizlized.
&gt; &gt; 2, Musl calls malloc before updating TLS size in dl stage 3.
&gt; &gt; 3, New created initial_tls doesn't carry builtin_tls's tsd.
&gt; &gt; 
&gt; &gt; 
&gt; &gt; The attached patch could fix this issue, please review it, thanks.
&gt; 
&gt; An interposed malloc being reachable before the crt1 entry point is a
&gt; bug that needs to be fixed. This is a context where it's not valid to
&gt; call any application-provided code. Where does the call happen from?
&gt; dynlink.c itself uses the internal malloc but I guess there's
&gt; somewhere the interposable malloc is getting called indirectly from.

I went looking for it and couldn't find any sign of malloc
reachability unless you go back to 1.2.1. Commit
c1e5d243b7e39b2fbfb17144608ce045575d8e95 removed the use via stdio,
and 34952fe5de44a833370cbe87b63fb8eec61466d7 switched to internal
malloc for all direct use from ldso. Are you just using a really old
version?

Rich