|Summary:||free() reports spurious "free(): invalid pointer" warning when realloc fails and MALLOC_CHECK_=1|
|Product:||[Fedora] Fedora||Reporter:||David Costanzo <david_costanzo>|
|Component:||glibc||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED RAWHIDE||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||2.3.5-3||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-04-28 20:43:10 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description David Costanzo 2005-03-31 20:14:32 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b) Gecko/20050217 Description of problem: glibc has a special "always available" heap debugger that can be turned on by setting the "MALLOC_CHECK_" enviornment variable. Its usage is explained on: http://www.delorie.com/gnu/docs/glibc/libc_33.html When MALLOC_CHECK_ is "1", free() prints a warning on this code: void * ptr = malloc(1); void * tmp = realloc(ptr, 0xFFFFFFFF); free(ptr); In this case, the call to realloc() fails because there isn't 4GB of memory available. When realloc() fails, the first argument is supposed to be unmodified. This means that we must free it. However, when free() is called, the following is printed: free(): invalid pointer 0x804a008! I will attach a C program that does the same thing (with error checks). Valgrind also reports an invalid memory free, so this may be a problem with the realloc() logic, not just the MALLOC_CHECK_ logic. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Compile realloctest.c 2. export MALLOC_CHECK_=1 3. ./realloctest.c Actual Results: The test print the following: malloc: using debugging hooks free(): invalid pointer 0x804a008! SUCCESS: realloc() correctly did nothing when asked to reallocate to 0xFFFFFFFF bytes Expected Results: It should print this: malloc: using debugging hooks SUCCESS: realloc() correctly did nothing when asked to reallocate to 0xFFFFFFFF bytes Additional info: This is a contrived repro scenario. In fact, I have only see this in contrived scenarios. I often give programs invalid/malicious input to test how robust they are. Sometimes, the invalid input is designed to force a large allocation. Even when the program-under-test is implemented properly, MALLOC_CHECK_ and valgrind will signal a failure. Because of this, I have filed may false bug reports. If this problem were fixed, it would be easier to test for memory corruption.
Comment 1 David Costanzo 2005-03-31 20:18:49 UTC
Created attachment 112538 [details] realloctest.c -- a sample application that demonstrates the problem
Comment 2 David Costanzo 2005-03-31 23:27:12 UTC
Someone just pointed out to me that I was using an old verson of valgrind. The latest valgrind (version 2.4.0) does NOT print out an error message for realloctest.c. Instead, it prints out a very reasonable message: ==9875== Warning: silly arg (-1) to realloc() So this probably IS just a problem with the MALLOC_CHECK_ code, and not realloc() overall.
Comment 3 Matthew Miller 2005-04-26 16:08:47 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
Comment 4 David Costanzo 2005-04-27 00:41:58 UTC
This is NOT a security issue. I will post back when I have been able to test this on FC3 or FC4.
Comment 5 Jakub Jelinek 2005-04-28 20:43:10 UTC
Should be fixed in glibc-2.3.5-3 and later in rawhide.