Dominik Stadler created XMLBEANS-676:
----------------------------------------
Summary: ThreadLocals in NamespaceContext are sometimes left over
and cause a memory leak
Key: XMLBEANS-676
URL: https://issues.apache.org/jira/browse/XMLBEANS-676
Project: XMLBeans
Issue Type: Bug
Affects Versions: 5.4.1
Reporter: Dominik Stadler
Attachments: image-2026-10-04-10-19-21-146.png,
image-2026-10-04-10-20-36-513.png
When running the large regression test-suite for Apache POI, I saw that over
time, more and more memory is allocated by thread-locals in NamespaceContext
and is not freed any more.
The test-application reads millions of documents in multiple threads. It
re-uses the threads for multiple documents.
Looking at memory dumps, it seems the thread-local in NamespaceContext keeps
considerable amounts of memory from being freed in at least two threads.
It seems sometimes the pushed elements are not pop()ed from the stack properly.
A quick look at the code did not show how this can happen, it seems calls to
"push()" are always followed by a "pop()" in a try-finally block. So elements
should always be removed again.
Also pop()ing the last item should always clear the thread-local, but one of
the two threads has an empty stack with "current" still holding onto a large
portion of memory.
The application is using Thread.stop() in some cases, but this should cause the
thread to be re-created by the executor and thus thread-locals to be freed. It
also causes all sorts of exceptions, including OOMs.
As a result, the regression testing application now runs very slowly as it
constantly causes OOMs as lots of memory is used by the thread-locals.
Thread holding onto memory in "current" inside the thread-local:
!image-2026-10-04-10-19-21-146.png!
Thread holding onto memory via a large number of elements remaining in the
stack:
!image-2026-10-04-10-20-36-513.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]