[gccsdk] ***Fatal error: Stack corruption detected***

[Jeffrey Lee]

(Apologies for not replying direct to the message in question - I've only 
just re-subscribed to the list. Original message linked to below [1])

After spending a few hours looking at some code that works fine on Linux 
but fails with stack/memory corruption on RISC OS, I tracked the problem 
area down to a situation similar to that described in bug 174 [2]. At a 
guess I'd say that my issue is the same as the one that Jan is having
with Vala, since it seems like a common enough code sequence for people
to encounter.

Basically my code was using a recursive function that sometimes uses 
alloca() and sometimes doesn't. The fix for bug 174 (judging by the 
comments in __gcc_alloca_restore in
gcc4/recipe/files/gcc/libunixlib/gcccompat/galloca.c) only deals with the 
situation where the alloca() has been skipped and the chunk list is empty. 
But in my case my recursive function means that the chunk list is often 
non-empty when alloca() is skipped, which would lead to 
__gcc_alloca_restore erroneously deleting the head chunk in the list when 
any non-alloca() code path exits. The test program I've attached can be
used to demonstrate this behaviour:

* 'test 3 1 2' will cause the recursion to go two levels deep, 
allocating one alloca()'d array at each level. This test works.
* 'test 2 1 2' will cause the recursion to go two levels deep, but only 
allocate a 'test' instance at the second level. This test also works (it 
would have crashed without the #174 fix)
* 'test 1 1 2' will cause the recursion to go two levels deep, but only 
calls alloca() at the first level. This currently crashes, due to 
__gcc_alloca_restore misbehaving as the second level exits, and deleting 
the chunk that the first level relied upon.

The easiest fix is likely to be to amend the NULL check that was added to 
__gcc_alloca_restore() for bug #174 so that it also returns if
(chunk->block != block). I'd have tested this myself by now, but something
is preventing my current source tree from building, so I'll have to try 
again in a day or two when I have some more time available to get my tree
working again.

[1] http://www.riscos.info/pipermail/gcc/2010-May/005275.html
[2] http://www.riscos.info/cgi-bin/bugzilla3/show_bug.cgi?id=174

Cheers,

- Jeffrey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cc
Type: application/octet-stream
Size: 634 bytes
Desc: 
URL: <http://www.riscos.info/pipermail/gcc/attachments/20100518/09b4f67a/attachment.obj>