From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id ca710dc9 for ; Tue, 28 Jan 2020 05:44:20 +0000 (UTC) Received: (qmail 16282 invoked by uid 550); 28 Jan 2020 05:44:18 -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 16247 invoked from network); 28 Jan 2020 05:44:17 -0000 To: musl@lists.openwall.com From: Leesoo Ahn X-TERRACE-DUMMYSUBJECT: Terrace Spam system * Message-ID: Date: Tue, 28 Jan 2020 14:44:07 +0900 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TERRACE-SPAMMARK: NO (SR:3.00) (by Terrace) Subject: [musl] Memory leak issue in multi-threaded program Dear musl developers, Hello!, it seems that musl currently has a memory leak issue in multi-threaded program. It occurs in the below situation of latest (v1.1.24) source. Also, not only in 32-bits[1], but also 64-bits[2] as well. When a program create and run, at least, two threads or more with pthread APIs, VSZ of the program by ps command keeps increasing. But here is a weird thing that it is fine 'IF ONLY ONE' pthread is created and run. To confirm the issue in your host machine, please follow the instructions, 0. Clone the musl git and get inside. 1. Build with these options for static build, ./configure --prefix=$(pwd)/_build_dir --disable-shared 2. Download the test code[3], then build with the command, ./_build_dir/bin/musl-gcc ./test.c 3. Run this script, ./a.out &; while [ 1 ]; do { ps aux | grep [a].out | grep -v grep; sleep 1; } done You may figure out that VSZ keeps increasing. BUT, when I make it to try to allocate memory all the time by kernel mmap with this diff[4] as workaround, although it creates more pthreads than 2, the issue never happens. It would be really thankful if you guys could confirm it and find out the way to fix the bug. Thank you in advance and take care. Best Regards, Leesoo ---- [1] 32-bits env: https://pastebin.com/xR4PySaM [2] 64-bits env: https://pastebin.com/stdVQXdE [3] test code: https://pastebin.com/0s8nmdUv [4] workaround patch: diff --git a/src/malloc/malloc.c b/src/malloc/malloc.c index 9698259..3d39be7 100644 --- a/src/malloc/malloc.c +++ b/src/malloc/malloc.c @@ -288,7 +288,11 @@ void *malloc(size_t n) if (adjust_size(&n) < 0) return 0; +#if 1 + if ( 1 ) { +#else if (n > MMAP_THRESHOLD) { +#endif size_t len = n + OVERHEAD + PAGE_SIZE - 1 & -PAGE_SIZE; char *base = __mmap(0, len, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);