Re: make check results

[Craig P Prescott <prescott at phys dot ufl dot edu>]

Hi;

Here's some info on the mips-sgi-irix6.5 "Memory Fault"s in make
check.

In block/:

GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "mips-sgi-irix6.5"...
(gdb) run
Starting program: /atlantic/tmp/prescott/work/gsl-0.7pre-cvs-20001010/block/test 
Sat Oct 14 02:42:08 EDT 2000
/atlantic/tmp/prescott/work/gsl-0.7pre-cvs-20001010/block
PASS: gsl_block_alloc returns valid pointer
[...]
PASS: gsl_block_complex_float_fprintf and fscanf work correctly

Program received signal SIGSEGV, Segmentation fault.
0x1000c164 in gsl_block_complex_long_double_fscanf (stream=0xfb4e640, 
    b=0xfb2cd78) at fprintf_source.c:85
85                data [MULTIPLICITY * i + k] = tmp;
(gdb) where
#0  0x1000c164 in gsl_block_complex_long_double_fscanf (stream=0xfb4e640, 
    b=0xfb2cd78) at fprintf_source.c:85
#1  0x100053a0 in test_complex_long_double_text () at test_complex_io.c:50
#2  0x10009e28 in main () at test.c:178
(gdb) l
80              {
81                ATOMIC_IO tmp ;
82
83                int status = fscanf (stream, IN_FORMAT, &tmp) ;
84                
85                data [MULTIPLICITY * i + k] = tmp;
86
87
88                if (status != 1)
89                  {
(gdb) p i
$1 = 1
(gdb) p k
$2 = 0
(gdb) p tmp
$3 = 1
(gdb) p &tmp
$4 = (long double *) 0x7fff2df0
(gdb) p data
$5 = (long double *) 0x0
(gdb) p b->data
$6 = (long double *) 0x20
(gdb) p n
$7 = 1027
(gdb) p b->size
$8 = 0
(gdb) p status
$9 = 0

Looks pretty screwy; n=1027 (correct), but b->size=0 ?  These things
are supposed to be equal.  Same weirdness with b->data (0x20?)  and
data (null).  tmp is correct, though, so the fscanf appears to be ok.
dbx gives the same results.

Now, this is weird - I put the following printf statements in:

--- fprintf_source.c_orig       Sat Oct 14 02:36:15 2000
+++ fprintf_source.c    Sat Oct 14 03:12:43 2000
@@ -73,6 +73,10 @@
 
   size_t i;
 
+  char *junk = IN_FORMAT;
+  printf("fscanf: %s 0x%p ",junk, b->data);
+  fflush(stdout);
+
   for (i = 0; i < n; i++)
     {
       int k;
@@ -148,6 +152,10 @@
                                   const size_t stride)
 {
   size_t i;
+
+  char *junk = IN_FORMAT;
+  printf("raw_fscanf: %s 0x%p ",junk, data);
+  fflush(stdout);
 
   for (i = 0; i < n; i++)
     {

and the block/test ran to completion, all PASSes.  For
gsl_block_complex_long_double_fscanf:

[...]
fscanf: %Lg 0x1002b090 PASS: gsl_block_complex_long_double_fprintf and fscanf work correctly
[...]

In matrix/, the test originally bombed thus:

[...]
PASS: gsl_matrix_float_fprintf and fscanf work correctly

Program received signal SIGSEGV, Segmentation fault.
0x1004cc10 in gsl_block_long_double_raw_fscanf (stream=0xfb4e640, data=0x0, 
    n=5671, stride=0) at fprintf_source.c:161
161               data [MULTIPLICITY * i * stride + k] = tmp;
(gdb) where
#0  0x1004cc10 in gsl_block_long_double_raw_fscanf (stream=0xfb4e640, 
    data=0x0, n=5671, stride=0) at fprintf_source.c:161
#1  0x100334b4 in gsl_matrix_long_double_fscanf (stream=0xfb4e640, 
    m=0x10072010) at file_source.c:136
#2  0x10012ee0 in test_long_double_text () at test_source.c:325
#3  0x10027284 in main () at test.c:148
(gdb) p i
$1 = 1
(gdb) p k
$2 = 0
(gdb) p tmp
$3 = 2
(gdb) p status
$4 = 0

tmp is right, data is null, and the failure was on the 2nd line
again.  With the patched fprintf_source.c:

[...]
raw_fscanf: %Lg 0x1007e2d8 FAIL: gsl_matrix_long_double_fprintf and fscanf work correctly
[...]
raw_fscanf: %Lg 0x10089410 FAIL: gsl_matrix_complex_long_double_fprintf and fscanf work correctly
[...]

In vector/, same story as in matrix/.  The test originally bombed thus:

[...]
PASS: gsl_vector_float_fprintf and fscanf work correctly

Program received signal SIGSEGV, Segmentation fault.
0x10033190 in gsl_block_long_double_raw_fscanf (stream=0xfb4e640, data=0x0, 
    n=1027, stride=0) at fprintf_source.c:161
161               data [MULTIPLICITY * i * stride + k] = tmp;
(gdb) where
#0  0x10033190 in gsl_block_long_double_raw_fscanf (stream=0xfb4e640, 
    data=0x0, n=1027, stride=0) at fprintf_source.c:161
#1  0x1002bd40 in gsl_vector_long_double_fscanf (stream=0x0, v=0x1)
    at file_source.c:56
#2  0x100108b0 in test_long_double_text () at test_io.c:46
#3  0x1002001c in main () at test.c:165
(gdb) p i
$1 = 1
(gdb) p k
$2 = 0
(gdb) p tmp
$3 = 1

With the print statements, the test still fails, but doesn't bomb:

[...]
raw_fscanf: %Lg 0x100581b8 FAIL: gsl_vector_long_double_fprintf and fscanf work correctly
[...]
raw_fscanf: %Lg 0x1005a1d0 FAIL: gsl_vector_complex_long_double_fprintf and fscanf work correctly
[...]

Bizarre.  It seems that gcc on IRIX can be a little funky
occassionally?  If anyone else has seen this (or not), let me know -
I'd be interested to know if it was just my gcc which was screwed up
:-/

If you'd like for me to check anything else out, let me know.  Maybe
I'll recompile the whole thing with -O0 and see if that helps, just to
understand this.

Cheers,
Craig
---
Craig Prescott                                (352) 846-3145 (Phone)
2011 New Physics Building                     (352) 392-8863 (Fax)
University of Florida, Gainesville, FL 32611  prescott@phys.ufl.edu