You should continue to report bugs to the JIRA bug tracker.
I have been doing significant evaluation of heap versus stack bugs.
There appears to be no standard solution to accommodate the true
process/thread stack address issues since the underlying system
architectures have no good way to dynamically reallocate operational
thread stack assignment space. Stack overflow in a thread causes
a segmentation fault that aborts the entire process.
As a senior application and systems architect, I normally create
a monitoring process that allows child processes to die and provide
features to allow critical systems to continue running when
the child processes fault and abort. The Xalan ans Xerces libraries
are built on pure C/C++ architectures without an overarching systems
monitoring process. Memory allocation for stack and heap is an
application design requirement because the C/C++ libraries are not
built on a platform advanced dynamic memory allocation fundamentals.
The Xalan and Xerces libraries allow for Out-of-Memory heap allocation
to be trapped and handled as exceptions. Process/Thread stack overflow
always creates a segmentation fault because stack allocation is static
and cannot be dynamically expanded by most operating systems.
If you find a good way to handle and recover from otherwise fatal
memory address segmentation faults, tell the world, patent the issue,
or go to work and get money from your design. Memory buffer overflows
are well understood and can be provided good protection. Heap
managers usually throw an out-of-memory exception. Stack overflow
usually results in a fatal segmentation fault.
Sincerely,
Steven J. Hathaway
On Thu, May 4, 2017 at 9:43 AM, Nicolas Grégoire
Post by Nicolas GrégoireHello,
I recently identified several vulnerabilities affecting Xalan-C v1.11.
While researching them, I noticed that a few of them are already listed
in the public bug tracker.
As an example, ticket XALANC-762 (created on 03/Apr/15) refers to a
https://issues.apache.org/jira/browse/XALANC-762
Should I report the other bugs I found in the bug tracker (or somewhere
else like a private mailing list)? Is there still any active
development of this code base?
I've not see much activity on Xalan-C. Recording bugs you find is always
nice but I am not sure you'll see any fixes. Hopefully someone else will
pipe in.
Gary
Post by Nicolas GrégoireRegards,
Nicolas Grégoire
---------------------------------------------------------------------
--
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Stack and Heap Overflow Analysis!
There appears to be no standard way to implement stack overflow protection.
Most always, the stack overflow manifests itself as a segmentation fault
that causes the entire process to abort.
The architecture used in C++ for Xalan and Xerces libraries do not use a
garbage collected memory management system and are therefore unable to
dynamically increase the size of stack space allocated to threads and
processes.
Java systems may implement dynamic memory management in a pure java runtime
environment, but not if JNI is used. Microsoft C# uses dynamic memory
implementing their proprietary .NET framework environment.
Native C/C++ requires that the application perform its own memory managemment
and does not benefit from the .NET framework garbage collection, intelligent
pointer movement, heap memory compression, and stack reallocation.
C/C++ systems are directly bound to the virtual address space allocated
to a process and its threads. Allocation of stack space for threads is
assigned at thread creation time. There is no standard way to proactively
determine how much stack space is available for pushing content onto the
stack such as subroutine and system calls to methods and functions.
The C++/STL containers have some semblance of stack architectures, but they
are dynamically implemented in the heap as allocated objects. The amount
of heap space in process virtual memory is also finite, but is independent
of the thread and process stack space.
Is the stack space vulnerability the process/thread stack space, or is it
the available heap memory consumed by C++/STL containers? When you exhaust
the stack, the most often result is a segmentation fault. When you exhaust
the heap space, an out-of-memory exception can generally be processed for
graceful recovery within the program.
A true process/thread stack overflow is fatal to the process. A heap
allocation (out-of-memory) does have a chance of graceful recovery and
error reporting.
An infinite recursive stylesheet creates a known abortive condition of
infinite memory consumption. It is encumbant of the application designer
to handle recursion limits. The library designer has no knowledge of
all application recursion template needs and therefore cannot and should
not arbitrarily enforce a maximum recursion depth. Such fixes can be handled
by the application designer.
Sincerely,
Steven J. Hathaway
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@xalan.apache.org
For additional commands, e-mail: dev-***@xalan.apache.org