RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

Joe Wang huizhe.wang at oracle.com
Mon Aug 15 19:08:45 UTC 2016


Hi Aleksej,

Note that DOM spec about error handling: If errors occur during the 
invocation of this method, such as an attempt to update a read-only node 
or a |Node.nodeName| contains an invalid character according to the XML 
version in use, errors or warnings (|DOMError.SEVERITY_ERROR| or 
|DOMError.SEVERITY_WARNING|) will be reported using the 
|DOMErrorHandler| object associated with the "error-handler " parameter. 
Note this method might also report fatal errors ( 
|DOMError.SEVERITY_FATAL_ERROR|) if an implementation cannot recover 
from an error.

So in this case, it doesn't seem to be "processing aborted by the user" 
as noted where RE was caught. When a DOM error happens, e.g. not 
wellformed, if no errorHandler is registered, the process will abort 
without an error. It's possible to handle the case without throw&catch 
RE. Please investigate.

Thanks,
Joe

On 8/15/16, 11:09 AM, Joe Wang wrote:
> Hi Aleksej,
>
> I suggest we get rid of the static abort. If RuntimeException happens, 
> check where it happens. The first use case looks suspicious as it just 
> returns if it's an instance of RE. For the 2nd case in DOM error 
> report, let's throw a RuntimeException with the specified error 
> message if error happens, and there's no handler or the handler failed 
> to handle it. (would be better than an empty RE)
>
> Best,
> Joe
>
> On 8/15/16, 10:38 AM, Aleks Efimov wrote:
>> Hi,
>>
>> Please, help to review the fix for memory leak [1] in 
>> com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused 
>> by usage of static final exceptions.
>> This problem was already fixed in Apache Xerces project [2] and I 
>> would like to backport it to JDK9 Xerces implementation.
>> Webrev with the changes:
>> http://cr.openjdk.java.net/~aefimov/8146961/9/00
>>
>> The Tomcat reproducer attached to the bug report fails without the 
>> fix and passes with the fix.
>> The JPRT and JCK testing shows no jaxp tests failures with the 
>> proposed fix.
>>
>> With Best Regards,
>> Aleksej
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8146961
>> [2] https://issues.apache.org/jira/browse/XERCESJ-1667
>>


More information about the core-libs-dev mailing list