Errors with a New Implementation of mpn/gcd.c

[Linas Vepstas]

On Wed, Mar 21, 2007 at 10:05:11PM -0400, Team GCD wrote:
>  
> What we can relate with some certainty is that there are instances where a pointer?s value (the vital pointers being up and vp) is getting rewritten to point to an inaccessible location (usually 0x0 or 0xffffffff). 

There are several tools that are handy for detecting memory corruption.
One of the simplest is "electric fence", and is commonly available on Linux
and other unixes. You simply link with libefence, and run your program
in gdb. It will then halt at the first place where the end of an array is
overwritten. You can also set it up to check for over-writing past the
begining of an array.

A far more thorough and sophisticated tool is valgrind, but you might find
it much harder to use. There are other tools as well, but these are the
big ones.

> We have not observed any specific instance where this behavior could occur, and therefore we have attributed it to stack management concerns whereby the locations storing these pointers are being clobbered by other data.

If its really a stack issue, then make sure that you are not allocating
on stack. A comon error that a Java programmer might make is to alloc on
stack, and then return a pointer that points into the stack!. e.g.

struct a { int x; int y};
struct a * func(void) { struct a sa; sa.x=1; sa.y=2; return &sa; }

Clearly the returned value will point at garbage!

--linas