From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1201 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 22:04:57 +0200 Message-ID: <1959429.eYcVRAGVSA@linuix> References: <20120609230541.47eac2de@newbook> <5041927.IR2Ri05J2P@linuix> <20120619191650.GP163@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 1340136187 32317 80.91.229.3 (19 Jun 2012 20:03:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 19 Jun 2012 20:03:07 +0000 (UTC) Cc: Rich Felker , musl@lists.openwall.com Bcc: bruno@haible.de To: bug-gnulib@gnu.org Original-X-From: musl-return-1202-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 19 22:03:05 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 1Sh4dk-0001PS-RK for gllmg-musl@plane.gmane.org; Tue, 19 Jun 2012 22:03:05 +0200 Original-Received: (qmail 22260 invoked by uid 550); 19 Jun 2012 20:03:04 -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 22252 invoked from network); 19 Jun 2012 20:03:04 -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: <20120619191650.GP163@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:1201 gmane.comp.lib.gnulib.bugs:31065 Archived-At: Rich Felker wrote: > > 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). > > musl's printf does not do anything with memory except using a small > constant amount of stack space (a few hundred bytes for non-float, > somewhere around 5-7k for floating point). This is completely > independent of the width/padding/precision; the implementation > actually goes to a good bit of trouble to ensure that it can print any > amount of padding efficiently without large or unbounded stack space > usage. > > Is there any way the rlimits put in place could be preventing the > stack from expanding beyond even one page the current number of pages, > etc.? I can reduce the program and the compilation options: =============================== conftest.c ============================= #include #include int main() { int ret; int err; ret = printf ("%.5000000f", 1.0); err = errno; fprintf (stderr, "printf's return value = %d, errno = %d\n", ret, err); return !(ret == 5000002 || (ret < 0 && err == ENOMEM)); } ======================================================================== $ musl-gcc -g -Wall conftest.c -o conftest $ ./conftest > /dev/null ; echo $? printf's return value = 5000002, errno = 0 0 $ ./conftest > /dev/null ; echo $? printf's return value = 5000002, errno = 0 0 $ ./conftest > /dev/null ; echo $? printf's return value = 5000002, errno = 0 0 $ ./conftest > /dev/null ; echo $? Speicherzugriffsfehler (Speicherabzug geschrieben) 139 $ ./conftest > /dev/null ; echo $? Speicherzugriffsfehler (Speicherabzug geschrieben) 139 I couldn't get useful info from gdb. This is on Linux, 32-bit mode on a 64-bit system. Can you reproduce this? Bruno