Re: valgrind still unhappy despite expect changes

On Thu, Sep 01, 2011 at 02:58:09PM -0300, Jorge Arellano Cid wrote:
> On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote:
> > On Thu, Sep 01, 2011 at 03:38:58PM +0200, Johannes Hofmann wrote:
> > > 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:
> 
> > > > > [...]
> > > > > In this one
> > > > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea274130.html
> > > > > at least, it looks pretty clear that the bw is gone.
> 
> 
> > > > [...]
> > > >   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.
> > 
> >   OK, this line gave light in that direction:
> > 
> > ==28991==  Address 0x6961a34 is 44 bytes inside a block of size 68 free'd
> > 
> >   ... and I observe that bw has 17 items, 17*4 = 68,
> >     and the expect URL is the 12th item, (12-1)*4 = 44.
> > 
> >   So it's an already freed 'bw' and not its expected URL.
> > 
> >   This starts to make sense...  ;-)


  FYI, looking into the other direction (a false positive), we have
this:

  "Valgrind Bug254420 - memory pool tracking broken"
    http://bugs.kde.org/show_bug.cgi?id=254420

  fixed in 3.6.1.


  If Jeremy or anybody can find a way to reproduce the log, we'd be
very close to nailing the issue down.

  @Jeremy: what do you get from valgrind using the procedure
described in my previous email?

  TIA.

-- 
  Cheers
  Jorge.-