Mismatched allocators (operator new[] and free) in gfxTextRun

VERIFIED DUPLICATE of bug 550805

Status

()

Core
Graphics
VERIFIED DUPLICATE of bug 550805
8 years ago
8 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

({valgrind})

Trunk
x86
Mac OS X
valgrind
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
I don't completely understand this valgrind complaint.  Is it due to the recent Gecko-wide allocator changes?

(Not attaching a testcase, but I think one of the testcases in bug 499862 triggers this code.)
(Reporter)

Comment 1

8 years ago
Created attachment 431467 [details]
valgrind complaint
I think this is a regression from bug 545989.
Depends on: 545989
The patch in bug 545989 was sound, AFAICS... it removes custom allocation (and the custom delete operator) from the gfxTextRun, and the factory Create() method now just uses operator new to create it. And for the auxiliary storage (mCharacterGlyphs array), it uses correctly-paired new (std::nothrow) [] and delete[].

However, looking at memory/mozalloc/mozalloc.h, I notice that it does not appear to redefine the (std::nothrow) variants of operator new / new[]. I think that's probably the root of the problem - and it will also apply to other callsites where we've used new (std::nothrow). There aren't many, but mxr finds a few examples in WebGL and Canvas as well as font code; and also some custom allocators in wince code that may need to be checked.
Mind fixing all those std::nothrows? :-)
(In reply to comment #3)
> However, looking at memory/mozalloc/mozalloc.h, I notice that it does not
> appear to redefine the (std::nothrow) variants of operator new / new[]. I think
> that's probably the root of the problem - and it will also apply to other
> callsites where we've used new (std::nothrow). There aren't many, but mxr finds
> a few examples in WebGL and Canvas as well as font code; and also some custom
> allocators in wince code that may need to be checked.

Yeah, this was my fault.  There's a patch floating around that adds (fallible) ::operator new(nothrow) to mozalloc, should land soon I hope.
This is really a dup of bug 550805, just reported in a different form.

(TBH, I don't actually understand why we're inventing mozilla::fallible instead of just using std::nothrow. Seems like that would be the standard C++ idiom for this functionality.)
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 550805

Updated

8 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.