Massive failures

[Steve Kargl]

On Wed, Apr 12, 2006 at 09:15:27PM -0700, Jerry DeLisle wrote:
> Steve Kargl wrote:
> >
> >I think I've come to some conclusion with the massive regressions.
> >A new memory allocator was committed to FreeBSD in mid-January,
> >and this is the first time I've updated since that allocator was
> >available.  This allocator has the feature that all newly allocated
> >or freed bytes of memory are set to 0xa5.  It appears that libgfortran
> >is making some really bad assumptions with regards to whether
> >memory is explicitly or implicitly bzero'd.
> >
> >With the following patch:
> >
> >Index: transfer.c
> >===================================================================
> >--- transfer.c	(revision 112881)
> >+++ transfer.c	(working copy)
> >@@ -2353,9 +2353,11 @@ st_write_done (st_parameter_dt *dtp)
> > 
> >       case NO_ENDFILE:
> > 	/* Get rid of whatever is after this record.  */
> >+#if 0
> > 	flush (dtp->u.p.current_unit->s);
> > 	if (struncate (dtp->u.p.current_unit->s) == FAILURE)
> > 	  generate_error (&dtp->common, ERROR_OS, NULL);
> >+#endif
> > 
> > 	dtp->u.p.current_unit->endfile = AT_ENDFILE;
> > 	break;
> >
> >I get the expected testsuite result:
> >
> If you look closely at the patch I submitted for PR26766 you will see that 
> I think I have fixed this. When allocating memory for the internal units, I 
> initialize to zero.  I also found at one point that I had to set 
> iunit->read_bad = 0;.  In some cases it wasn't zero and that gives an error 
> right away.
> 
> Regardless, it became clear that our initialization of internal units was 
> very weak and we have only been lucky things worked so far.
> 
> I was about to PING this patch (pr26766) for a review.  One of the 
> iterations I had not done yet was eliminating some of the specific variable 
> initializations since now I am setting the whole structure to '\0'.  I 
> chose not to because I wanted to capture in the code what must be 
> initialized.  So far, with the code shown in the patch, things look solid.
> 

Yes, your patch for 26766 fixes the regressions I'm seeing.
Based on your tests against Dale's torturous code, I think
this patch should be applied.  BTW, I was testing 4.1, but
I suspect the patch is the same for trunk.

One good thing about my preference for FreeBSD is that it 
has a completely different C library from glibc.  We'll
eventually catch all of these problems.

-- 
Steve