Bug 153003 - free() reports spurious "free(): invalid pointer" warning when realloc fails and MALLOC_CHECK_=1
free() reports spurious "free(): invalid pointer" warning when realloc fails ...
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-03-31 15:14 EST by David Costanzo
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.3.5-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-28 16:43:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
realloctest.c -- a sample application that demonstrates the problem (831 bytes, text/x-csrc)
2005-03-31 15:18 EST, David Costanzo
no flags Details

  None (edit)
Description David Costanzo 2005-03-31 15:14:32 EST
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:


When MALLOC_CHECK_ is "1", free() prints a warning on this code:

  void * ptr = malloc(1);
  void * tmp = realloc(ptr, 0xFFFFFFFF);

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:

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 15:18:49 EST
Created attachment 112538 [details]
realloctest.c -- a sample application that demonstrates the problem
Comment 2 David Costanzo 2005-03-31 18:27:12 EST
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 12:08:47 EDT
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-26 20:41:58 EDT
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 16:43:10 EDT
Should be fixed in glibc-2.3.5-3 and later in rawhide.

Note You need to log in before you can comment on or make changes to this bug.