[xsde-users] State stack: memory corruption for stacks >= 8, with patch

[Boris Kolpackov]

Hi Klaus,

Klaus Kuehnhammer <klaus at bitstem.com> writes:

> - in stack.ixx (libxsde), push() grows the stack one call too late,
> causing top() to point beyond the allocated region when the stack size
> reaches the default of 8.

The bug is actually in top(), not in push(). The top() function
incorrectly returns one element past the current. I have fixed
this and the patch is available here:

http://scm.codesynthesis.com/?p=xsde/xsde.git;a=commitdiff;h=38fc036f9884a0f4c1a6ed1e684dc39938b2539f;hp=ce65e0086daf4458209118e9935609950e387b13


> - in the generated _start_element_impl, top() is called once before the
> recursive state machine calls. If the stack is grown during this, the
> existing states are copied to a new memory location (grow() in
> stack.cxx). The element-local reference vs is never updated and still
> reads from the old, already delete[]'d stack buffer.

Hm, I analyzed the code in _start_element_impl() and I don't see how
this is possible. The only call that can grow the stack is the call
to one of compositor functions at the end of the function. But after
that call the stack is not accessed.

I think here is what happens: because your fix for the first issue
is not correct, you are still observing the effect of this bug. In
fact, I managed to reproduce it on our tests by lowering the initial
capacity. Without the fix under valgrind I see invalid memory accesses
while with the fix everything runs cleanly.

Can you try to apply the patch above and see if this fixes everything
without your patch for the second problem.

And thanks for reporting this!

Boris