[
https://issues.apache.org/jira/browse/XERCESC-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor closed XERCESC-1979.
---------------------------------
> OutOfMemoryException being thrown on creation of an LS Serializer
> -----------------------------------------------------------------
>
> Key: XERCESC-1979
> URL: https://issues.apache.org/jira/browse/XERCESC-1979
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
> Affects Versions: 3.1.1
> Environment: AIX 6.1 and AIX 7.1
> 32-bit binary distribution libraries of Xerces 3.1.1
> Compiler (on AIX 6.1):
> IBM XL C/C++ for AIX, V11.1 (5724-X13)
> Version: 11.01.0000.0000
> Driver Version: 11.01(C/C++) Level: 100304
> C Front End Version: 11.00(C/C++) Level: 100301
> C++ Front End Version: 11.01(C/C++) Level: 100304
> High-Level Optimizer Version: 11.01(C/C++) and 13.01(Fortran) Level: 100301
> Low-Level Optimizer Version: 11.01(C/C++) and 13.01(Fortran) Level: 100304
> Reporter: Matt Dissinger
> Assignee: Alberto Massari
> Fix For: 3.1.2, 3.2.0
>
> Attachments: Xerces MemoryManagerImpl Patch.zip
>
>
> I am seeing with one of my companies' unit test binaries an
> OutOfMemoryException being thrown when attempting to create an LS serializer.
> The program code in question is:
> {code}
> xercesc::DOMImplementation* impl =
> DOMImplementationRegistry::getDOMImplementation(XMLString::transcode("LS"));
> impl->createLSSerializer();
> {code}
> We are currently only seeing this with one of our unit test binaries, and
> only on AIX. We haven't seen this yet on our production binaries or on
> Solaris, RedHat Enterprise Linux, or Windows. The root cause is an
> allocation of 0 bytes for which the ::operator new is returning a NULL
> pointer, and the MemoryManagerImpl throws an OutOfMemoryException when this
> occurs. This happens as a result of the DOMLSSerializerImpl object
> allocating a RefVectorOf with an initial size of 0, and the base class
> BaseRefVectorOf's constructor calling allocate with 0 bytes.
> Even though the C++ standard does allow for allocations of 0 bytes, it is a
> potential point of failure that can be avoided by not attempting the 0 byte
> allocation. Since the standard does define that dereferencing a pointer
> returned as a request for zero size is undefined, it should be safe to return
> NULL for 0 byte allocations (3.7.4.1 - Allocation functions, point 2, from
> the draft version here:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf).
> I've tested a change to the MemoryManagerImpl class which checks for 0 byte
> allocations and immediately returns NULL rather than attempting an ::operator
> new (0), and it has fixed the issue in our AIX environments.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
