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/7ea9fc809376ddf7dde2908e2ecf999aea27413... 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.