From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1193 Path: news.gmane.org!not-for-mail From: Bruno Haible Newsgroups: gmane.linux.lib.musl.general,gmane.comp.lib.gnulib.bugs Subject: Re: musl, printf out-of-memory test Date: Tue, 19 Jun 2012 12:45:50 +0200 Message-ID: <5041927.IR2Ri05J2P@linuix> References: <20120609230541.47eac2de@newbook> <12545931.v3ALTEUUx8@linuix> <20120619001156.GJ163@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: dough.gmane.org 1340102648 11869 80.91.229.3 (19 Jun 2012 10:44:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 19 Jun 2012 10:44:08 +0000 (UTC) Cc: Rich Felker , musl@lists.openwall.com, Isaac Dunham Bcc: bruno@haible.de To: bug-gnulib@gnu.org Original-X-From: musl-return-1193-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 19 12:44:07 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Sgvuj-0001vm-US for gllmg-musl@plane.gmane.org; Tue, 19 Jun 2012 12:44:02 +0200 Original-Received: (qmail 5439 invoked by uid 550); 19 Jun 2012 10:44:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5423 invoked from network); 19 Jun 2012 10:44:00 -0000 X-RZG-AUTH: :Ln4Re0+Ic/6oZXR1YgKryK8brksyK8dozXDwHXjf9hj/zDNRbvY44zMkpA== X-RZG-CLASS-ID: mo00 User-Agent: KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; ) In-Reply-To: <20120619001156.GJ163@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:1193 gmane.comp.lib.gnulib.bugs:31046 Archived-At: Rich Felker wrote: > > Replacements of *printf, because of > > [...] > > checking whether printf survives out-of-memory conditions... no > > No idea. Copying out the test and running it directly, it passes just > fine for me. Maybe gnulib has already replaced printf with its own > malloc-using version by the time it gets to this test?? Strange indeed. With a testdir of all of gnulib, I got configure:17615: checking whether printf survives out-of-memory conditions configure:17786: /arch/x86-linux/inst-musl/bin/musl-gcc -std=gnu99 -o conftest -g -O2 -Wall conftest.c >&5 configure:17789: $? = 0 configure:17837: result: yes but with a testdir of only the POSIX related modules of gnulib, I got configure:13657: checking whether printf survives out-of-memory conditions configure:13828: /arch/x86-linux/inst-musl/bin/musl-gcc -std=gnu99 -o conftest -g -O2 -Wall conftest.c >&5 configure:13831: $? = 0 configure:13879: result: no The '$? = 0' line prints only the linker's exit code, not the runtime exit code. I'm adding a second output line for the runtime exit code. Then I get: configure:8919: checking whether printf survives out-of-memory conditions configure:9090: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 -Wall conftest.c >&5 configure:9093: $? = 0 configure:9097: $? = 1 configure:9142: result: no After adding a printf to stderr: Once I get configure:8919: checking whether printf survives out-of-memory conditions configure:9093: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 -Wall conftest.c >&5 configure:9096: $? = 0 printf's return value = 5000002, errno = 0 configure:9100: $? = 0 configure:9145: result: yes In another configure run I get: configure:8919: checking whether printf survives out-of-memory conditions configure:9093: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 -Wall conftest.c >&5 configure:9096: $? = 0 configure:9100: $? = 1 configure:9145: result: no So, the exit code 1 must have come from the crash handler. Without this crash handler: 7x I get configure:8919: checking whether printf survives out-of-memory conditions configure:8979: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 -Wall conftest.c >&5 configure:8982: $? = 0 printf's return value = 5000002, errno = 0 configure:8986: $? = 0 configure:9031: result: yes but once I get configure:8979: /arch/x86-linux/inst-musl/bin/musl-gcc -o conftest -g -O2 -Wall conftest.c >&5 configure:8982: $? = 0 configure:8986: $? = 139 configure:9031: result: no So, apparently, under memory stress, musl's printf has a probability of between 10% and 50% of crashing with SIGSEGV (139 = 128 + 11). Bruno 2012-06-19 Bruno Haible *printf-posix: Put more info into config.log. * m4/printf.m4 (gl_PRINTF_ENOMEM): Emit conftest's error output and exit code into config.log. --- m4/printf.m4.orig Tue Jun 19 12:41:56 2012 +++ m4/printf.m4 Tue Jun 19 12:41:53 2012 @@ -1,4 +1,4 @@ -# printf.m4 serial 48 +# printf.m4 serial 49 dnl Copyright (C) 2003, 2007-2012 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -1028,8 +1028,9 @@ changequote([,])dnl ])]) if AC_TRY_EVAL([ac_link]) && test -s conftest$ac_exeext; then - (./conftest + (./conftest 2>&AS_MESSAGE_LOG_FD result=$? + _AS_ECHO_LOG([\$? = $result]) if test $result != 0 && test $result != 77; then result=1; fi exit $result ) >/dev/null 2>/dev/null