On Thu, 22 Jan 2004, Henrik Nordstrom wrote: > I will defenitely try the ssp and mudflap approaches immediately (pending > installation first..).
mudflap tried, but unfortunately it does not seem to trap this specific error. A guess is that the corruption occurs within a libc call and as my libc is not mudflap instrumented... But mudflap looks very good regardless of this. Defenitely a very good tool to have in the toolbox. I wonder if maybe valgrind can be extended to protect return and frame pointer addresses on the stack. If it can then that would work quite well for this type of error exacly where it happens. But valgrind should be able to see this on the return if I only manage to trigger the bug under valgrind.. Regards Henrik
