moz_xrealloc aborts with moz_handle_oom/mozalloc_abort, when size = 0

RESOLVED DUPLICATE of bug 723472

Status

()

Core
Memory Allocator
--
major
RESOLVED DUPLICATE of bug 723472
7 years ago
7 years ago

People

(Reporter: Sean Leonard, Unassigned)

Tracking

11 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(firefox11-, firefox12-)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0
Build ID: 20120129021758

Steps to reproduce:

In a component that I am working on, we call:

nsMemory::Realloc(ptr, size)

sometimes with size > 0, and sometimes with size = 0. As of Firefox 11, this function calls NS_Realloc, which calls NS_Realloc_P, which ultimately calls moz_xrealloc.


Actual results:

When size = 0, the following code is executed:
    void* newptr = realloc(ptr, size);
    if (UNLIKELY(!newptr)) {
        mozalloc_handle_oom();
        return moz_xrealloc(ptr, size);
    } 

This code is executed because realloc returns NULL.


Expected results:

realloc can return NULL when size = 0, as documented in various C library documentation references. In some implementations, realloc can return a non-NULL unique pointer (see http://pubs.opengroup.org/onlinepubs/7908799/xsh/realloc.html), but returning NULL and freeing as if free() is called, is at least the norm on MS Visual C++. This is not an error or a low-memory condition: it's to be expected.

However, the current implementation of moz_xrealloc thinks that realloc is "infalliable" in the wrong sense. In this case, realloc is returning NULL successfully for the input argument size = 0.

The current code causes materially different behavior for relying functions, such as nsMemory::Realloc, resulting in unexpected aborts.
(Reporter)

Updated

7 years ago
Severity: normal → major
(Reporter)

Comment 1

7 years ago
See nsMemoryImpl.cpp, mozalloc.cpp, and mozalloc_oom.cpp.
This is bad.
tracking-firefox11: --- → ?
tracking-firefox12: --- → ?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 723472
(Reporter)

Comment 4

7 years ago
Thanks; however, I would like to request that it be fixed in Firefox 11 and Firefox 12. (So +1 for tracking/blocking tracking-firefox11 and tracking-firefox12.)
I agree, but lets handle that over there.
Created attachment 602254 [details] [diff] [review]
Fix leaks on CORS failures in imagelib.
Attachment #602254 - Flags: review?(joe)
Attachment #602254 - Attachment is obsolete: true
Attachment #602254 - Flags: review?(joe)

Updated

7 years ago
tracking-firefox11: ? → -
tracking-firefox12: ? → -
We took the fix on Aurora, and the backout on Beta, so this should be fixed for Firefox 11.
You need to log in before you can comment on or make changes to this bug.