<AWT Dev> RFR: 8181139: Memory leak in awt_Font.cpp / AwtFont::Create

Semyon Sadetsky semyon.sadetsky at oracle.com
Thu Nov 9 19:15:10 UTC 2017


OK, looks good.

--Semyon


On 11/09/2017 11:10 AM, Phil Race wrote:
> I don't see how it can be safe to do that.
> That is more likely to lead to a crash than to free memory.
> In the loop the awtFont is made to reference several HFONTs and
> added to a disposer to release these. If the awtFont is freed and the 
> disposer
> then run it will be a bad thing.
>
> I'd far sooner have that leak than the crash.
>
> And it seems like this can only happen if memory allocation fails.
> ie if the AwtFont could not be constructed to begin with .. so
> there isn't even then a valid thing to free.
>
> If anything this points to the issue that all the calls to throw 
> std::bad_alloc()
> make clean-up hard but it is a risky project to modify all of that.
>
> -phil.
>
>
> On 11/08/2017 04:55 PM, semyon.sadetsky at oracle.com wrote:
>> Should not it be deleted in the catch block as well?
>>
>> --Semyon
>>
>>
>> On 11/8/17 4:13 PM, Philip Race wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181139
>>> Webrev : http://cr.openjdk.java.net/~prr/8181139/
>>>
>>> if we aren't using / returning the awtFont C object we should free 
>>> (delete) it before returning
>>> to avoid a leak in this theoretical situation.
>>>
>>> The object has only just been allocated and doesn't have any clean 
>>> up that needs to be
>>> done besides calling its C++ destructor.
>>>
>>> [NB sending to awt-dev, not 2d-dev since this C++ Windows-specific 
>>> class is used only to
>>> support Composite Logical Fonts on AWT GDI heavyweights .. ]
>>>
>>> -phil.
>>
>



More information about the awt-dev mailing list