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
