bug-gnulib
[Top][All Lists]
Advanced

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

Re: done digging around test-dprintf-posix2


From: Bruno Haible
Subject: Re: done digging around test-dprintf-posix2
Date: Mon, 10 Jan 2011 21:44:46 +0100
User-agent: KMail/1.9.9

Bruce Korb wrote:
> 1. 4MB pages -- don't know, but I doubt it.  This is an out-of-the-box
>    openSuSE 11.3 installation for x86-64.

OK, then it's likely the standard 4 KB page size.

> 2. I do not think I need those sizes, since I have a core image.
>    That core image is just under 300K.

The core file is not necessarily an entirely faithful image of the address
space of the running process. Can you provide the contents of the
/proc/pid/maps file
  1. at the point before entering dprintf,
  2. at the point where dprintf returns with -1 / ENOMEM?
There are two ways to have enough time to produce this:
  a. under gdb, add a breakpoint.
  b. add a sleep(30); statement at the appropriate location.

>    my recommendation is to hand it off
>    to the malloc folks for some help.  They might be completely
>    correct that this is a kernel problem.  It even seems somewhat
>    likely to me at this point.

OK, then the next step is to modify the program that you showed yesterday
to not use dprintf() any more, just malloc(). Attach this program, which only
makes getrlimit(), setrlimit(), malloc() calls to the glibc bug.

Then, try to reduce it even further: Replace the malloc() call with an mmap()
call similar to the first one that was visible in the system call trace.
This program,  which only makes getrlimit(), setrlimit(), mmap() calls,
should be something that you can pass on to the kernel people to convince them
that there's a bug on their side.

Bruno



reply via email to

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