bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

done digging around test-dprintf-posix2


From: Bruce Korb
Subject: done digging around test-dprintf-posix2
Date: Fri, 07 Jan 2011 15:50:53 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11

Hi,

On Fri, Jan 7, 2011 at 2:58 PM, Bruce Korb <address@hidden> wrote:
> I reported this issue as a bug to glibc:
> http://sourceware.org/bugzilla/show_bug.cgi?id=12232
> and the unsurprising result is they said, "go away".
> But one kind soul asked for an ltrace on the failing program.
> That causes the test to succeed, likely because ltrace doesn't
> pass through the exit code.  It did "exit(1)" but the test
> thought everything was working.  In any case, this isn't the
> same problem because the original problem was an allocation failure.
> Maybe if I dig far enough, it will show a malloc issue in
> "rpl_dprintf()"?
>
> I'll keep digging while I have a little time, but the same two
> tests are failing:  test-fprintf-posix3 and test-dprintf-posix2
>
> ==> /tmp/dprintf-684-1.ltrc <==
> __libc_start_main(0x400860, 2, 0x7fff8ecc0778, 0x4009b0, 0x400a40 <unfinished 
> ...>
> getrlimit(2, 0x7fff8ecc0670, 0x7fff8ecc0790, 0x2b27ce7984a8, 0x2b27ce799320) 
> = 0
> setrlimit(2, 0x7fff8ecc0670, 0x7fff8ecc0790, -1, 0x2b27ce799320) = 0
> getrlimit(9, 0x7fff8ecc0670, 0x7fff8ecc0790, -1, 0x2b27ce799320) = 0
> setrlimit(9, 0x7fff8ecc0670, 0x7fff8ecc0790, -1, 0x2b27ce799320) = 0
> strtol(0x7fff8ecc21a5, 0, 10, -1, 0x2b27ce799320) = 1
> rpl_dprintf(1, 0x400a9c, 17, 1, 0x2b27ce798580)  = 0xffffffff
> __errno_location()                               = 0x2b27ce9bcac8
> +++ exited (status 1) ++
>

That was a failure not noticed because ltrace exited 0 instead of 1.
ltrace printed the errno location instead of the errno, but the code would
only do that if the errno were actually 12 (ENOMEM).

I now believe it completely correct to add this:  free(malloc(0x88))
to the program and put it into the main line until the real cause
(glibc or kernel) is determined and fixed.

Clear to send?  Thanks -Bruce

$ vc-dwim --commit
tests: exercise malloc a tiny bit before setting the rlimit.
* tests/test-dprintf-posix2.c: the test occasionally fails on Linux
if setrlimit is called before any malloc call.
* tests/test-fprintf-posix3.c: likewise

2011-01-04  Bruce Korb  <address@hidden>
diff --git a/tests/test-dprintf-posix2.c b/tests/test-dprintf-posix2.c
index 9fd869a..60e898d 100644
--- a/tests/test-dprintf-posix2.c
+++ b/tests/test-dprintf-posix2.c
@@ -64,6 +64,7 @@ main (int argc, char *argv[])
 #endif
   /* On Linux systems, malloc() is limited by RLIMIT_AS.  */
 #ifdef RLIMIT_AS
+  free (malloc (0x88));
   if (getrlimit (RLIMIT_AS, &limit) < 0)
     return 77;
   if (limit.rlim_max == RLIM_INFINITY || limit.rlim_max > MAX_ALLOC_TOTAL)
diff --git a/tests/test-fprintf-posix3.c b/tests/test-fprintf-posix3.c
index 90a2f7c..646df1b 100644
--- a/tests/test-fprintf-posix3.c
+++ b/tests/test-fprintf-posix3.c
@@ -63,6 +63,7 @@ main (int argc, char *argv[])
 #endif
   /* On Linux systems, malloc() is limited by RLIMIT_AS.  */
 #ifdef RLIMIT_AS
+  free (malloc (0x88));
   if (getrlimit (RLIMIT_AS, &limit) < 0)
     return 77;
   if (limit.rlim_max == RLIM_INFINITY || limit.rlim_max > MAX_ALLOC_TOTAL)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]