xplor-nih segfaults

[Jerry DeLisle]

Hi all,

I have got some useful information from valgrind now.  There are a couple of 
problems going on here.  xplor-nih is using an uninitialized variable.  This may 
be an artifact of the arguments in the call to decodf being cray-pointers.

The second problem, possibly related to the first, is that the formatted 
transfer is not getting past the required type check and its calling 
format_error.  This format_error call is consistent across multiple transfers. 
The segfault looks like it may be a latent off-by-one error in format_error.  Of 
course we should NOT be getting a format error in the first place.

I will take a whack at the format_error problem.

Asher, can you look at the pointer situation.  The format is expecting a 
character type.

Jack, can you look at the xplor-nih code and see if you can see a problem there.

I will feed more info if you need, just ask.

Regards,

Jerry

See output below from valgrind:

(2) ==4183== Use of uninitialised value of size 8
(2) ==4183==    at 0x1BF5E22F: decodf_ (string.f:334)
(2) ==4183==    by 0x1BF02489: tbp_read_ (parmio.f:1087)
(2) ==4183==    by 0x1BF019FC: parrd2_ (parmio.f:915)
(2) ==4183==    by 0x1BEFD205: parrdr_ (parmio.f:46)
(2) ==4183==    by 0x1B923101: xplor_parse_ (xplorFunc.f:517)
(2) ==4183==    by 0x8048B89: main (xplor.c:116)
(2) ==4183==
(2) ==4183== Invalid write of size 1
(2) ==4183==    at 0x1B90A6BA: memcpy (mac_replace_strmem.c:285)
(2) ==4183==    by 0x1D5CA6BB: _gfortrani_format_error (format.c:926)
(2) ==4183==    by 0x1D5D048B: require_type (transfer.c:431)
(2) ==4183==    by 0x1D5D1178: formatted_transfer (transfer.c:632)
(2) ==4183==    by 0x1D5CFB5F: _gfortran_transfer_character (transfer.c:883)
(2) ==4183==    by 0x1B91B941: cread_ (coorio.f:425)
(2) ==4183==    by 0x1BD9F7C3: corma2_ (corman.f:153)
(2) ==4183==    by 0x1BD9F347: corman_ (corman.f:37)
(2) ==4183==    by 0x1B92280A: xplor_parse_ (xplorFunc.f:446)
(2) ==4183==    by 0x8048B89: main (xplor.c:116)
(2) ==4183==  Address 0x52BFD2BF is just below %esp.  Possibly a bug in GCC/G++
(2) ==4183==   v 2.96 or 3.0.X.  To suppress, use: --workaround-gcc296-bugs=yes