[petsc-dev] Did someone fucking break bfort?

[Satish Balay]

Can you send me the valgrind.log - with the patch applied to the
unmodified sowing-1.1.11-a.tar.gz?

Also the command you are using to generate this log?


I've used the following:
valgrind --tool=memcheck -q --log-file=valgrind.log bfort -dir `pwd`/ftn-auto -ansi -nomsgs -noprofile -anyname -mapptr -mpi -mpi2 -ferr -ptrprefix Petsc -ptr64 PETSC_USE_POINTER_CONVERSION -fcaps PETSC_HAVE_FORTRAN_CAPS -fuscore PETSC_HAVE_FORTRAN_UNDERSCORE matrix.c

Satish

On Fri, 25 Dec 2009, Matthew Knepley wrote:

> Valgrind is not clean for me with the change.
> 
>   Matt
> 
> On Fri, Dec 25, 2009 at 10:28 AM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> > Well - normally the first step with detecting the bugs is to report
> > them to the author - and ask for a fix..
> >
> > Satish
> >
> > On Fri, 25 Dec 2009, Matthew Knepley wrote:
> >
> > > I can try, but I still think replacement is the only real alternative.
> > This
> > > is not
> > > able to be debugged, or you would not recommend sticking in random
> > numbers
> > > in malloc() and I would be able to see where an SEGV occurs with gdb.
> > >
> > >   Matt
> > >
> > > On Fri, Dec 25, 2009 at 10:16 AM, Satish Balay <balay at mcs.anl.gov>
> > wrote:
> > >
> > > > BTW: What linux are you using? ubuntu version? i686 or x86_64? etc...
> > > >
> > > > also try:
> > > >
> > > > arg->name     = (char *)MALLOC( strlen(p) + 100 );
> > > >
> > > > satish
> > > >
> > > >
> > > > On Fri, 25 Dec 2009, Satish Balay wrote:
> > > >
> > > > > Did my suggested change not work for you?
> > > > >
> > > > > Satish
> > > > >
> > > > > On Thu, 24 Dec 2009, Matthew Knepley wrote:
> > > > >
> > > > > > I spent a bunch of time on this today. This shit is hopelessly
> > broken.
> > > > It
> > > > > > sucks completely.
> > > > > > I cannot get it to run, nor see why it is causing stack overruns
> > and
> > > > SEGVs.
> > > > > > If anyone does
> > > > > > not think it is hopeless, speak up now. This is a complete fucking
> > > > > > embarrassment.
> > > > > >
> > > > > >    Matt
> > > > > >
> > > > > > On Mon, Dec 21, 2009 at 4:42 PM, Matthew Knepley <
> > knepley at gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > This does not make any sense to me because it would be a heap
> > > > violation,
> > > > > > > not a stack smash.
> > > > > > >
> > > > > > >   Matt
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Dec 21, 2009 at 4:30 PM, Satish Balay <balay at mcs.anl.gov
> > >
> > > > wrote:
> > > > > > >
> > > > > > >> [I don't know the correct fix for this - but ] The following
> > change
> > > > is
> > > > > > >> getting rid of valgrind messages for me. Maybe you can use this,
> > > > build
> > > > > > >> sowing separately - and continue..
> > > > > > >>
> > > > > > >> Satish
> > > > > > >>
> > > > > > >> ----------
> > > > > > >>
> > > > > > >> diff -r dbe25084c0e4 src/bfort/bfort.c
> > > > > > >> --- a/src/bfort/bfort.c Mon Dec 15 22:20:58 2008 -0600
> > > > > > >> +++ b/src/bfort/bfort.c Mon Dec 21 16:29:09 2009 -0600
> > > > > > >> @@ -2157,7 +2157,7 @@
> > > > > > >>
> > > > > > >>     /* Current token is name */
> > > > > > >>     arg->has_star = (nstar > 0);
> > > > > > >> -    arg->name     = (char *)MALLOC( strlen(p) + 1 );
> > > > > > >> +    arg->name     = (char *)MALLOC( strlen(p) + 10 );
> > > > > > >>     strcpy( arg->name, p );
> > > > > > >>
> > > > > > >>     /* We can't output the name just yet, because if it is
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Mon, 21 Dec 2009, Matthew Knepley wrote:
> > > > > > >>
> > > > > > >> > The problem appears to be in OutputRoutine() in bfort.c, but
> > that
> > > > code
> > > > > > >> is
> > > > > > >> > impossible
> > > > > > >> > to debug. I can't see where something is getting overwritten,
> > and
> > > > it
> > > > > > >> looks
> > > > > > >> > like the check
> > > > > > >> > only happens when the routine returns. bfort is such crap.
> > > > > > >> >
> > > > > > >> >   Matt
> > > > > > >> >
> > > > > > >> > On Mon, Dec 21, 2009 at 3:25 PM, Matthew Knepley <
> > > > knepley at gmail.com>
> > > > > > >> wrote:
> > > > > > >> >
> > > > > > >> > > On Mon, Dec 21, 2009 at 3:21 PM, Satish Balay <
> > > > balay at mcs.anl.gov>
> > > > > > >> wrote:
> > > > > > >> > >
> > > > > > >> > >> On Mon, 21 Dec 2009, Lisandro Dalcín wrote:
> > > > > > >> > >>
> > > > > > >> > >> > On Mon, Dec 21, 2009 at 5:37 PM, Matthew Knepley <
> > > > > > >> knepley at gmail.com>
> > > > > > >> > >> wrote:
> > > > > > >> > >> > >
> > > > > > >> > >> > > It says there is a stack smash and no other info. This
> > is
> > > > > > >> completely
> > > > > > >> > >> fucking
> > > > > > >> > >> > > my development right now.
> > > > > > >> > >> > >
> > > > > > >> > >> >
> > > > > > >> > >> > Any chance bfort was built with -fstack-protector flag?
> > This
> > > > > > >> failure
> > > > > > >> > >> > could could be signaling an actual old bug in bfort... I
> > > > would
> > > > > > >> > >> > re-build bfort with debug and re-run under valgrind...
> > > > > > >> > >>
> > > > > > >> > >> That must be it.
> > > > > > >> > >>
> > > > > > >> > >> I just ran my build [which is without -fstack-protector] -
> > and
> > > > > > >> > >> valgrind does flag a bunch of things with bfort.
> > > > > > >> > >>
> > > > > > >> > >
> > > > > > >> > > 1) That flag is nowhere in my build.
> > > > > > >> > >
> > > > > > >> > > 2) Something changed
> > > > > > >> > >
> > > > > > >> > >   Matt
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >> I normally install sowing separately and have it in my PATH
> > -
> > > > so that
> > > > > > >> > >> it doesn't have to be rebuilt each time I build petsc.
> > > > > > >> > >>
> > > > > > >> > >> I guess we should sync up [our patches] with latest sowing
> > and
> > > > make
> > > > > > >> > >> sure its valgrind clean aswell.
> > > > > > >> > >>
> > > > > > >> > >> Satish
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > --
> > > > > > >> > > What most experimenters take for granted before they begin
> > their
> > > > > > >> > > experiments is infinitely more interesting than any results
> > to
> > > > which
> > > > > > >> their
> > > > > > >> > > experiments lead.
> > > > > > >> > > -- Norbert Wiener
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > What most experimenters take for granted before they begin their
> > > > > > > experiments is infinitely more interesting than any results to
> > which
> > > > their
> > > > > > > experiments lead.
> > > > > > > -- Norbert Wiener
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > >
> >
> 
> 
> 
>