mpz_mul core dump - attempt 2

[Kate Minola]

Kate Minola <kminola at po0.glue.umd.edu> writes:

  The following C code seg faults on the 
  sparc-SunOS architecture (but not on
  other architectures that I have tried):
  
  --------------------------------------
  #include "gmp.h"
  int main()
  {
    gmp_randstate_t rstate;
    mpz_t a, b;
    mpz_init(a);
    mpz_init(b);
    gmp_randinit_default(rstate);
    mpz_urandomb(a, rstate, 1 << 26);
    mpz_mul(b, a, a);
  }
  --------------------------------------

Torbjorn writes:
    
  This is almost certainly stack overflow.

****************************************************

On the sparc-SunOS I have (ultrasparc2-sun-solaris2.8),

$ ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        8192
coredump(blocks)     unlimited
nofiles(descriptors) 256
vmemory(kbytes)      unlimited
$
$ ./foo
Segmentation Fault(coredump)
$ 
$ 
$ ulimit -s 16892
$ ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        16892
coredump(blocks)     unlimited
nofiles(descriptors) 256
vmemory(kbytes)      unlimited
$ 
$ ./foo
Segmentation Fault(coredump)
$ 

Yet on an x86-SunOS (pentium4-pc-solaris2.8) with
stacksize of 8480 kbytes, the above program finishes
normally.

I tried rebuilding gmp-4.1.3 with 
    --enable-alloca=malloc-reentrant
and later with
    --enable-alloca=malloc-notreentrant

The above code when linked with either of those builds
still coredumps when run (using either of the stack sizes
above).

All compiles were done with gcc-3.4.1.

I would be grateful for any suggestions of what I am
doing wrong or overlooking.  If anyone can get the
above code to run normally on their sparc-SunOS
machine, what stack size are you using?

Kate Minola
University of Maryland, College Park