Good point! I'm afraid it will take me the rest of my life
to reproduce under valgrind .. but ... I'll see what I can do....
In the meantime -- I'm not sure what to do with a Jira if the
provenance is in doubt...
----- Original Message -----
> This isn't necessarily a proton bug. Nothing in the referenced checkin
> actually touches the logic around allocating/freeing error strings, it
> merely causes pn_send/pn_recv to make use of pn_io_t's pn_error_t where
> previously it threw away the error information. This would suggest that
> there is perhaps a pre-existing bug in dispatch where it is calling
> pn_send/pn_recv with a pn_io_t that has been freed, and it is only now
> triggering due to the additional asserts that are encountered due to not
> ignoring the error information.
> I could be mistaken, but I would try reproducing this under valgrind. That
> will tell you where the first free occurred and that should hopefully make
> it obvious whether this is indeed a proton bug or whether dispatch is
> somehow freeing the pn_io_t sooner than it should.
> (FWIW, if it is indeed a proton bug, then I would agree it is a blocker.)
> On Wed, Feb 25, 2015 at 7:54 AM, Michael Goulish <mgoul...@redhat.com>
> > ...but if not, somebody please feel free to correct me.
> > The Jira that I just created -- PROTON-826 -- is for a
> > bug I found with my topology testing of the Dispatch Router,
> > in which I repeatedly kill and restart a router and make
> > sure that the router network comes back to the same topology
> > that it had before.
> > As of checkin 01cb00c -- which had no Jira -- it is pretty
> > easy for my test to blow core. It looks like an error
> > string is being double-freed (maybe) in the proton library.
> > ( full info in the Jira. https://issues.apache.org/jira/browse/PROTON-826
> > )