From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20448 invoked from network); 1 Jan 2022 14:32:18 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Jan 2022 14:32:18 -0000 Received: (qmail 18099 invoked by uid 550); 1 Jan 2022 14:32:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18067 invoked from network); 1 Jan 2022 14:32:16 -0000 Message-ID: <54060b8f-2ff1-fa1c-abc7-ac4996858ffb@m-labs.hk> Date: Sat, 1 Jan 2022 22:31:58 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: musl@lists.openwall.com References: <08c0476d-3ad5-85fe-f2bd-51bf8c21268a@m-labs.hk> <1641045086.i0hohehzro.none@localhost> From: Sebastien Bourdeauducq In-Reply-To: <1641045086.i0hohehzro.none@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] building statically linked DSOs with musl On 1/1/22 21:58, Alex Xu (Hello71) wrote: > First, > malloc implementations (may) use a process-global resource: (s)brk. It > will cause havoc if multiple implementations attempt to simultaneously > manipulate it. Second, even if no more than one implementation uses > (s)brk, they will still have incompatible metadata. Can't there be two different heaps in different memory regions? > Consider the case > where your plugin allocates some memory with malloc, then passes the > pointer to Python which then frees it. Since an incompatible > implementation is processing it, it will most likely destroy the heap or > crash. Well yes, that's a fairly obvious issue and we are not doing that; the side that allocates the memory is always the one that frees it. Sébastien