On 11/18/10 09:10, Bruce Korb wrote: > The limit assigned is not 1 byte, but 10 million. > The process space after the setrlimit call is far smaller. > Whatever underlying call malloc uses (beit "sbrk" or even "mmap") > should *NOT* fail. The bug is not in the test. Either glibc > or the kernel -- perhaps even both. Please notice that > adding the following line at the start of the program evades the issue: > > free (malloc (0x88));
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) ++
