bug-gnulib
[Top][All Lists]
Advanced

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

Re: patch for printf memory use tests


From: Bruce Korb
Subject: Re: patch for printf memory use tests
Date: Sat, 15 Jan 2011 07:51:04 -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

On 01/15/11 05:48, Bruno Haible wrote:
>> $ readelf --segments *core*
> 
> Interesting. I didn't know about this command.

Hi Bruno,

So much magic and so little time.....I had used it a bit over a
year ago, but I, too, needed something to remind me.

> Anyway, the bottom line is that the dynamic loader is free to
> add many unwanted and large entries to the address space.
> Here it was 2 MB per shared library. It could also have been
> 128 MB per shared library.

I know of some commercial code that deliberately limits address
space.  When they get around to upgrading to a system that
has a 2MB alignment for libraries, they're going to get bitten.  Hard.

> I conclude that the right thing to do is to setrlimit (RLIMIT_AS,) with a 
> value
> that is computed as
> (size of address space of current process before any malloc) + 10 MB.

I tried to do that by playing with setrlimit calls, but I cannot seem
to get the call to fail on Linux, except when trying to expand the
hard limit.  It fails only on that.

> I believe we can implement a function that returns the size of the address
> space for most platforms, and on the remaining platforms (AIX, HP-UX, IRIX,
> OSF/1) we haven't seen these failures.

I am not familiar enough with those platforms.  Don't have access, either.

>> 3. The test is designed to catch a mis-implementation of the printf
>>    functionality.
> 
> More generally, we're talking about the infrastructure to catch any kind
> of memory leak in a library function.

This has not, at this point, proven to be a general problem.
Just these two printf tests.

> I disagree. The ability to check against memory leaks is an important feature
> in the test suite, and it warrants jumping through a number of hoops.

Perhaps then it is worth testing more directly by replacing the
memory management calls in the memory leak tests?

> When this is done, we can change the memory leak tests to use this
> function.

I grepped for setrlimit in the tests.  There are only two rlimit tests
that do an operation over and over for the purpose of detecting a leak.
They are the two printf functions at issue.  The general notion of
catching leaks in the gnulib implementations is a good idea.  But the
tests currently doing that are both specifically for testing printf.
They are probably redundant tests (testing the same code for the same
problem).  The likelihood that they will be re-broken with a memory
leak is small.  The likelihood of a different function being coded up
with a leak is higher, but that isn't being tested.

So, I still think that specifically testing printf for a leak belongs
in a tested-for-a-stable-release suite, not the every-time-you-test-it
suite.  Were there a more generally usable leak test, that would make
more sense for an every time suite.

For now, bumping the repeat count to 1500 is the crucial part.
I think the try-it-once tests in the is-it-functional test should
be done now, replacing it with enhanced functionality when the
enhanced functionality is ready.

Regards, Bruce



reply via email to

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