Re: valgrind still unhappy despite expect changes

On Thu, Sep 01, 2011 at 09:57:39AM -0300, Jorge Arellano Cid wrote:
> On Wed, Aug 31, 2011 at 09:42:21PM +0000, corvid wrote:
> > Jorge wrote:
> > > On Tue, Aug 30, 2011 at 06:19:38PM +0100, Jeremy Henty wrote:
> > > > 
> > > > Jorge Arellano Cid wrote:
> > > > 
> > > > > On Tue, Aug 30, 2011 at 12:34:59AM +0100, Jeremy Henty wrote:
> > > > > > 
> > > > > > I  compile Dillo  with  'configure "CFLAGS=-g  -O0" "CXXFLAGS=  -g
> > > > > > -O0"' to minimise false positives from gcc optimization.
> > > > > 
> > > > >   Ack.
> > > > > 
> > > > >   Given you got  the log. Do you  have a way to reproduce  it, or at
> > > > > least have a memory of what you were doing?
> > > > 
> > > > Unfortunately no.   I automatically run dillo inside  valgrind and log
> > > > the output.  A cron job reads the logs and updates the reports.  These
> > > > days I  rarely even look at  the logs unless something  in the mailing
> > > > list prompts me to.
> > > > 
> > > > I am  wondering how to add  debugging information that  could help tie
> > > > valgrind reports to Dillo's actions.   Perhaps the CCC could log which
> > > > of its  chains is active and which  URL it was serving?   Then if dlib
> > > > logged its allocations and frees  maybe we could identify the URL that
> > > > was responsible?
> > > 
> > >   Even  having the URL wouldn't help much in this case because we
> > > need  to  know  which  "cancel" action triggered the last call to
> > > a_Nav_cancel_expect_if_eq().  This  would  require  logging  user
> > > actions.
> > > 
> > >   OTOH,  trying  to  re-build  a user action pattern from the CCC
> > > logs would be almost impossible for a human brain (if possible at
> > > all). ;)
> > > 
> > >   More technically:
> > > 
> > >   Each  bw  has  its  own  nav_expect_url;  a  private  copy of a
> > > DilloUrl. Valgrind complains about nav_expect_url, not the bw. So
> > > I  wonder  how  can  the  bw be valid and not the nav_expect_url,
> > > which is either NULL or a private copy of a DilloUrl?
> > 
> > In this one
> > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea274130.html
> > at least, it looks pretty clear that the bw is gone.
> 
>   Oh, it may be my mistake then.
> 
> ==28991== Invalid read of size 4
> ==28991==    at 0x805760A: a_Bw_expected_url (bw.c:336)
> 
>   bw.c:336
>     return bw->nav_expect_url;
> 
>   Does the invalid read apply to 'bw' or 'bw->nav_expect_url'?
>   (I don't know valgrind's semantics on it)

I'd guess bw is no longer pointing to valid memory (i.e. has been
free'd) and therefore reading the 4 byte nav_expect_url pointer
causes the valgrind message.