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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_FONT_FACE_BAD,HTML_FONT_LOW_CONTRAST, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, T_KAM_HTML_FONT_INVALID autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9768 invoked from network); 20 Sep 2022 00:26:05 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2022 00:26:05 -0000 Received: (qmail 9403 invoked by uid 550); 20 Sep 2022 00:26:02 -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 9380 invoked from network); 20 Sep 2022 00:26:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:mime-version:references:subject:cc:to:from:date:from:to :cc:subject:date; bh=o9ZjG42clwYygFtNFGZYPH+SW6fhUwvhpbdnh+zdHYI=; b=RIrMRU/QWRu+0Jo5wlYaPLH3HFYWtqq2AZ0ymSabYmlpbiFdN5YJhz/r9G714M1Ac+ /46+dFq5HLmHhpQVapYL7ofn4ME9vsAaV+kYTCG9tltqASkv+O+y/K53NR/dpGRru70A FCj7LjyfnoBtmfdY8NhdI5rdu7fPNNhqtnyvBz4Fwq9rVBsYT6YrO5vk14A3Ly6FtHkE uq+ILw6lIoA3WUldWrh9AE/9NgXiZWq23y705FymJnLKcek9fYvDhp1YVsPQdW4LeBRM sKUuUpEJji78SFme4mwRrl7XFJmJ34bOrGtK/fV/vbyhfOOg6U7a1TAC2m9VHwf64yGP PKwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=message-id:mime-version:references:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=o9ZjG42clwYygFtNFGZYPH+SW6fhUwvhpbdnh+zdHYI=; b=BplSA6NuWf/eAtcrDzguEwUW2jxx4MMtU2J/guAfScLFBfJkgyDHL82CAakH45Xz2t SsDOLbmM8en9FpqmyWz1dgKAPRz3XIqptxMkkeDILWOx420S8HBoEZAGuRryoFu6+q3N q8BG6GjIOaKAwgNj4SnUUlG5xhGE5efDb+br2D+r5IzGtLJxNBnYXgdYF4NUEuu1ZNl0 2mqwv8oaypLYrtjBHC/ycLTQsFX71wAFhw66euzXRVdLC7BAiGPZ7ZnF/Chhrt8xMnQ4 E80xP3KRlNvTYQUFkqLWC401tDVpDz1+SyeGi44QXOdKWCGOdLMHVbUzi5bZxOcxWfLY Y/DQ== X-Gm-Message-State: ACrzQf20cFUnnEDZo4HKlUBn09QyArDtwVpU+IQosyMT4jdiM41DZk+l P5/YakDHKse4/bo/HhodnE4= X-Google-Smtp-Source: AMsMyM7Z8Rp5srLIebJCQmhXWUZ5wAhRXW9TzRV0TDu2esNUDZJoi1YDxd0Ib0h4Z2IETNLbxSJscg== X-Received: by 2002:a63:5766:0:b0:439:f684:f08f with SMTP id h38-20020a635766000000b00439f684f08fmr9507231pgm.575.1663633549545; Mon, 19 Sep 2022 17:25:49 -0700 (PDT) Date: Tue, 20 Sep 2022 08:25:52 +0800 From: baiyang To: "James Y Knight" Cc: musl , "Florian Weimer" References: <2022091915532777412615@gmail.com>, <20220919110829.GA2158779@port70.net>, <874jx3h76u.fsf@oldenburg.str.redhat.com>, <20220919134659.GO9709@brightrain.aerifal.cx>, , <2022092001404698842815@gmail.com>, X-Priority: 3 X-GUID: 346535CE-FD7C-4192-A9F9-510E2A52BD40 X-Has-Attach: no X-Mailer: Foxmail 7.2.23.116[cn] Mime-Version: 1.0 Message-ID: <2022092008254998320584@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart168667616227_=----" Subject: Re: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) This is a multi-part message in MIME format. ------=_001_NextPart168667616227_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QXMgR2FicmllbCBzYWlkLCBpdCdzIG5vdCBhIFVCLiBDb250cmFyaWx5LCBpdCBpcyBhIGJ1ZyBp biBnY2MncyBNc2FuLg0KSnVzdCByZWFkIG1vcmUgb24gdGhpcyB0aHJlYWQgOi0pIA0KIA0KLS0N Cg0KICAgQmVzdCBSZWdhcmRzDQogIEJhaVlhbmcNCiAgYmFpeWFuZ0BnbWFpbC5jb20NCiAgaHR0 cDovL2kuYmFpeS5jbg0KKioqKiA8IEVORCBPRiBFTUFJTCA+ICoqKiogDQogDQogDQpGcm9tOiBK YW1lcyBZIEtuaWdodA0KRGF0ZTogMjAyMi0wOS0yMCAwODoxMw0KVG86IGJhaXlhbmcNCkNDOiBt dXNsOyBGbG9yaWFuIFdlaW1lcg0KU3ViamVjdDogUmU6IFJlOiBbbXVzbF0gVGhlIGhlYXAgbWVt b3J5IHBlcmZvcm1hbmNlIChtYWxsb2MvZnJlZS9yZWFsbG9jKSBpcyBzaWduaWZpY2FudGx5IGRl Z3JhZGVkIGluIG11c2wgMS4yIChjb21wYXJlZCB0byAxLjEpDQpPbiBNb24sIFNlcCAxOSwgMjAy MiBhdCAxOjQwIFBNIGJhaXlhbmcgPGJhaXlhbmdAZ21haWwuY29tPiB3cm90ZToNCkhpIEphbWVz LA0KDQpJIGxvb2tlZCBhdCB0aGUgY29kZSBvZiB0Y21hbGxvYywgYnV0IEkgZGlkbid0IGZpbmQg YW55IG9mIHRoZSBwcm9ibGVtcyB5b3UgbWVudGlvbmVkIGluIHRoZSBpbXBsZW1lbnRhdGlvbiBv ZiBtYWxsb2NfdXNhYmxlX3NpemUgKHNlZTogaHR0cHM6Ly9naXRodWIuY29tL2dvb2dsZS90Y21h bGxvYy9ibG9iLzkxNzliYjg4NDg0OGMzMDYxNjY2N2JhMTI5YmNmOWFmZWUxMTRjMzIvdGNtYWxs b2MvdGNtYWxsb2MuY2MjTDEwOTkgKS4NCg0KT24gdGhlIGNvbnRyYXJ5LCBzaW1pbGFyIHRvIG11 c2wsIHRjbWFsbG9jIGFsc28gZGlyZWN0bHkgdXNlcyB0aGUgcmV0dXJuIHZhbHVlIG9mIG1hbGxv Y191c2FibGVfc2l6ZSBpbiBpdHMgcmVhbGxvYyBpbXBsZW1lbnRhdGlvbiB0byBkZXRlcm1pbmUg d2hldGhlciBtZW1vcnkgbmVlZHMgdG8gYmUgcmVhbGxvY2F0ZWQ6IGh0dHBzOi8vZ2l0aHViLmNv bS9nb29nbGUvdGNtYWxsb2MvYmxvYi85MTc5YmI4ODQ4NDhjMzA2MTY2NjdiYTEyOWJjZjlhZmVl MTE0YzMyL3RjbWFsbG9jL3RjbWFsbG9jLmNjI0wxNDk5DQoNCkkgdGhpbmsgdGhpcyBpcyBlbm91 Z2ggdG8gc2hvdyB0aGF0IHRoZSByZXR1cm4gdmFsdWUgb2YgbWFsbG9jX3VzYWJsZV9zaXplIGlu IHRjbWFsbG9jIGlzIGFjY3VyYXRlIGFuZCByZWxpYWJsZSwgb3RoZXJ3aXNlIGl0cyBvd24gcmVh bGxvYyB3aWxsIGNhdXNlIGEgc2VnbWVudCBmYXVsdC4NCg0KSXQgcmV0dXJucyBhbiBhY2N1cmF0 ZSB2YWx1ZSwgYnV0IGl0IGlzIHVuZGVmaW5lZCBiZWhhdmlvciB0byBhY3R1YWxseSBfdXNlXyB0 aGF0IG1lbW9yeS4gWW91IG5lZWQgdG8gZmlyc3QgY2FsbCByZWFsbG9jIC0tIGFuZCB3aGVuIGNh bGxpbmcgcmVhbGxvYywgeW91IChwcm9iYWJseS4uLikgbmVlZCB0byBhY2Nlc3MgdGhlIG5ldyBt ZW1vcnkgdmlhIHRoZSByZXR1cm4gdmFsdWUgb2YgdGhlIHJlYWxsb2MgY2FsbCwgcmF0aGVyIHRo YW4gdGhlIHBvaW50ZXIgeW91IHBhc3NlZCBhcyBpbnB1dCAtLSBldmVuIGlmIHRoZXkgaGFwcGVu IHRvIGhhdmUgdGhlIHNhbWUgaW50ZWdlciByZXByZXNlbnRhdGlvbi4gKFRob3VnaCB0aGVyZSdz IGNlcnRhaW5seSBwbGVudHkgb2YgZGViYXRlL2Rpc2N1c3Npb24gcmVnYXJkaW5nIHRoZSBleGFj dCB3b3JraW5ncyBvZiwgYW5kIGFkdmlzYWJpbGl0eSBvZiwgc3VjaCAncG9pbnRlciBwcm92ZW5h bmNlIiBydWxlcy4uLikuIEluIGFueSBjYXNlLCBjYWxsaW5nIHRoZSBmdW5jdGlvbiBpbnNpZGUg dGhlIG1hbGxvYyBpbXBsZW1lbnRhdGlvbiB0byBpbXBsZW1lbnQgcmVhbGxvYyBpcyBhIGRpZmZl cmVudCBtYXR0ZXIgZW50aXJlbHkgZnJvbSB1c2VyIGNvZGUgY2FsbGluZyBpdC4NCg0KQW5kLCBu b3RlIHRoYXQganVzdCBiZWNhdXNlIHNvbWV0aGluZyB3b3JrcyBmb3IgeW91IHRvZGF5IGRvZXNu J3QgbWVhbiBpdCdzIGNvcnJlY3Qgb3IgYWxsb3dlZC4gSXQganVzdCBtZWFucyB0aGF0IHlvdSd2 ZSBiZWVuIGFibGUgdG8gZ2V0IGF3YXkgd2l0aCBpdC4gU28gZmFyLiBVbnRpbCBvbmUgZGF5IGl0 IHN0b3BzIHdvcmtpbmcuIFRoYXQncyB0aGUgcmVhbGx5IGZ1biBwYXJ0IG9mIFVuZGVmaW5lZCBC ZWhhdmlvci4uLg0K ------=_001_NextPart168667616227_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
As Gabriel said, it's not a UB.= Contrarily, it is a b= ug in gcc's Msan.
Just read more on this thread :-) 
=0A
 
=0A
--=

&n= bsp;  Best Regards
  BaiYang
&= nbsp; baiyang@gmail.com
&= nbsp; http://i.baiy.cn
**** < END OF EMAIL &g= t; **** 
 
 
Date: 2022-09-20 08:13
To: baiyang
Subject: Re: Re: [musl] The heap m= emory performance (malloc/free/realloc) is significantly degraded in musl = 1.2 (compared to 1.1)
On Mon, Se= p 19, 2022 at 1:40 PM baiyang <baiyang@gmail.com> wrote:
=0A
Hi James,

I looked at the code of tcmalloc, but I didn't f= ind any of the problems you mentioned in the implementation of malloc_usab= le_size (see: <= a href=3D"https://github.com/google/tcmalloc/blob/9179bb884848c30616667ba1= 29bcf9afee114c32/tcmalloc/tcmalloc.cc#L1099" style=3D"background-color:tra= nsparent;font-family:=E6=96=B0=E5=AE=8B=E4=BD=93" target=3D"_blank" rel=3D= "noreferrer">https://github.com/google/tcmalloc/blob/9179bb884848c30616667= ba129bcf9afee114c32/tcmalloc/tcmalloc.cc#L1099 ).

On the contrary, similar to musl, tcmalloc al= so directly uses the return value of malloc_usable_size in its realloc imp= lementation to determine whether memory needs to be reallocated: https://github.com/google/tcmalloc/blob/9179bb884848c30616667ba129bcf9af= ee114c32/tcmalloc/tcmalloc.cc#L1499
=0A

I think this is enough to show that the retur= n value of malloc_usable_size in tcmalloc is accurate and reliable, otherwise its own realloc will cause a segment fault.
=
It returns an accurate value, but it is undefined behavior = to actually _use_ that memory. You need to first call realloc -- and = when calling realloc, you (probably...) need to access the new memory via = the return value of the realloc call, rather than the pointer you passed a= s input -- even if they happen to have the same integer representation. (T= hough there's certainly plenty of debate/discussion regarding the exact wo= rkings of, and advisability of, such 'pointer provenance" rules...). In an= y case, calling the function inside the malloc implementation to implement= realloc is a different matter entirely from user code calling it.

And, note that just because so= mething works for you today doesn't mean it's correct or allowed. It just = means that you've been able to get away with it. So far. Until one day it = stops working. That's the really fun part of Undefined Behavior...
=0A
=0A ------=_001_NextPart168667616227_=------