In message <d974c30f51.jan-j...@iyonix.c2i.net>
Jan-Jaap van der Geer <jjvdg...@inbox.com> wrote:
> I build the latest version of Vala (0.8.1) and tried to compile one
> of my programs. Vala worked for a bit, and then gave an error:
>
> ***Fatal error: Stack corruption detected***
>
> I tried compiling the same code under Vala in Linux, where it
> compiled with no problem.
>
> [...]
>
> I think the conclusion of this is that something is upsetting newer
> versions of the Vala compiler, possibly unixlib or gcc. Does that
> sound reasonable?
Yes, entirely. The msg is given by UnixLib during its stack management
when it notices that there is something seriously wrong (btw, there isn't
a stack dump given ?). Note that the moment of this detection and the
moment the problem really happened can be quite apart in time.
To go over the possible causes in more detail:
1. It might be a bug in Vala, i.e. something ordinary as simply overwriting
its runtime stack : pointer to local array, writing via that pointer but
outside that array. Or a pointer to local variable is used outside its
context, i.e. after the runtime stack has been unwinded.
A shot in the dark would be to use valgrind on the same Vala version and
compile the same program on your Debian machine. And/or just consult the
Vala community and check if a similar problem has been reported.
2. It might be a bug in UnixLib in its stack routines. The best approach
to test this theory is to make a customer UnixLib build with in
include/unixlib/buildoptions.h __UNIXLIB_PARANOID and
__UNIXLIB_EXTREMELY_PARANOIND set to 1. At runtime, UnixLib will perform
more runtime sanity checks (at expense of speed of course) and hopefully
detect the problem earlier. It has been a while I had to use these build
options so I hope the paranoid code hasn't bitrotted over time.
Practically:
- Change recipe/files/gcc/unixlib/include/unixlib/buildoptions.h
- Either do a full rebuild.
Either when you already have made a build and want to do a partial
rebuild:
- cd builddir/cross-gcc
- make
- make install
You need to re-cross-compile Vala (or do at least a relink) for the new
UnixLib with those paranoid checks. Run this on RISC OS and hopefully
this will reveal something interesting.
3. It might be a bug in gcc/UnixLib concerning alloca()/setjmp() use. This
is all about variable stack slot claims which need to automatically unrolled
when setjmp() is done. I explicitely mention this because it is tricky
code in gcc and UnixLib and not commonly used. If you don't see alloca()
/setjmp(), nor C99 variable arrays being used in Vala, then we can rule
this out. Nevertheless, this would also be flagged using the UnixLib
paranoid checks.
> If so, is there anything that can be done to resolve it?
See above, lots and there is no standard recipe to pinpoint this.
Good luck !
John.
--
John Tytgat, in his comfy chair at home BASS
john.tyt...@aaug.net ARM powered, RISC OS driven
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
