For your information. http://starurchin.org/dillo/valgrind.html It lists the valgrind errors from my most recent Dillo sessions. It's just one big static HTML page at the moment. Feel free to suggest how it could be more useful. You can see we're still getting lots of small leaks from the CSS parser, though the big ones have been fixed by recent commits. Regards, Jeremy Henty
On Sat, Feb 14, 2009 at 06:35:48PM +0000, Jeremy Henty wrote:
For your information.
http://starurchin.org/dillo/valgrind.html
It lists the valgrind errors from my most recent Dillo sessions. It's just one big static HTML page at the moment. Feel free to suggest how it could be more useful.
One URL that reproduces each leak would be very helpful. Repeated leaks can be omitted. -- Cheers Jorge.-
On Sat, Feb 14, 2009 at 05:04:27PM -0300, Jorge Arellano Cid wrote:
On Sat, Feb 14, 2009 at 06:35:48PM +0000, Jeremy Henty wrote:
For your information.
http://starurchin.org/dillo/valgrind.html
It lists the valgrind errors from my most recent Dillo sessions. It's just one big static HTML page at the moment. Feel free to suggest how it could be more useful.
One URL that reproduces each leak would be very helpful.
Would having a single page with anchors for each link be enough, or do you want separate pages for each one?
Repeated leaks can be omitted.
It should already be doing that. I extract the suppression (the part in { ... }) and eliminate duplicates based on that. It's not perfect because different code paths may trigger the same error. I'm hoping it proves to be good enough. I can't see an easy way to do better. Suggestions are welcome. Regards, Jeremy Henty
On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote:
On Sat, Feb 14, 2009 at 05:04:27PM -0300, Jorge Arellano Cid wrote:
On Sat, Feb 14, 2009 at 06:35:48PM +0000, Jeremy Henty wrote:
For your information.
http://starurchin.org/dillo/valgrind.html
It lists the valgrind errors from my most recent Dillo sessions. It's just one big static HTML page at the moment. Feel free to suggest how it could be more useful.
One URL that reproduces each leak would be very helpful.
Would having a single page with anchors for each link be enough, or do you want separate pages for each one?
A single page seems easier.
Repeated leaks can be omitted.
It should already be doing that. I extract the suppression (the part in { ... }) and eliminate duplicates based on that. It's not perfect because different code paths may trigger the same error. I'm hoping it proves to be good enough. I can't see an easy way to do better. Suggestions are welcome.
Usually when fixing one of these bugs, a few others dissappear. But you're right is hard to tell before the fix. You can erase the ones belonging to FLTK. -- Cheers Jorge.-
On Sat, Feb 14, 2009 at 07:04:21PM -0300, Jorge Arellano Cid wrote:
On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote:
Would having a single page with anchors for each link be enough, or do you want separate pages for each one?
A single page seems easier.
Actually, I've gone for a summary page with links to a separate page for each error. I've put some information from the stack traces into the link texts. I think it works rather well, eg. you can clearly see that most of the errors are coming from CSS handling (and some of those leaks are not as small as I thought). Please comment. http://starurchin.org/dillo/valgrind.html If you find spurious entries then tell me and I'll add the suppressions to my Dillo/Valgrind script and they won't appear in subsequent log files. I'll do all the ones that come from FLTK, so you needn't point those out. Regards, Jeremy Henty
On Sun, Feb 15, 2009 at 02:14:53AM +0000, Jeremy Henty wrote:
On Sat, Feb 14, 2009 at 07:04:21PM -0300, Jorge Arellano Cid wrote:
On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote:
Would having a single page with anchors for each link be enough, or do you want separate pages for each one?
A single page seems easier.
Actually, I've gone for a summary page with links to a separate page for each error. I've put some information from the stack traces into the link texts. I think it works rather well, eg. you can clearly see that most of the errors are coming from CSS handling (and some of those leaks are not as small as I thought). Please comment.
It looks much more insightful. But, I miss the URL to reproduce the BUG. That's what I meant in the previous email; please excuse me if it wasn't clear. That's the starting point for debugging. Even if only a few have their URLs that's a good start. We can point new developers to this page too, as usually this bugs are not too complex to fix. -- Cheers Jorge.-
On Sun, Feb 15, 2009 at 09:17:09AM -0300, Jorge Arellano Cid wrote:
But, I miss the URL to reproduce the BUG. That's what I meant in the previous email; please excuse me if it wasn't clear.
Oh, I see. Unfortunately I don't have that information, the code just parses the output of Valgrind. When an error occurs there is no indication which of the current pages produced it. Worse, valgrind only reports leaks after the program exits. I haven't been able to find a specific example that reproduces any of these problems. I strongly suspect that the errors we are seeing now are non-deterministic and come from race-like conditions between different pages. Every time I run dillo on a single page the valgrind report is clean. Maybe there's some deep valgrind magic that would yield more information, but if so I don't know of it. Any ideas? Regards, Jeremy Henty
On Sun, Feb 15, 2009 at 02:14:53AM +0000, Jeremy Henty wrote:
On Sat, Feb 14, 2009 at 07:04:21PM -0300, Jorge Arellano Cid wrote:
On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote:
Would having a single page with anchors for each link be enough, or do you want separate pages for each one?
A single page seems easier.
Actually, I've gone for a summary page with links to a separate page for each error. I've put some information from the stack traces into the link texts. I think it works rather well, eg. you can clearly see that most of the errors are coming from CSS handling (and some of those leaks are not as small as I thought). Please comment.
Thanks for testing! Unfortunately I don't have valgrind running here. Do the dates on the page mean that the CSS related leaks mostly started with dillo sources from after 2009-02-12? Regards, Johannes
On Sun, Feb 15, 2009 at 06:13:27PM +0100, Hofmann Johannes wrote:
Do the dates on the page mean that the CSS related leaks mostly started with dillo sources from after 2009-02-12?
No. I show each error once at the most recent time that it appeared in any log. There is no indication of how long the error has been appearing (although I could add it if it would be useful). All you can infer is that each error was unfixed on the day it was logged (at least in my repository, which I try to keep up to date). Also, statistically, errors near the top of the page are probably fairly commonm, and those near the bottom are probably either fixed or rare. Regards, Jeremy Henty
Hi Jeremy, in your valgrind there are still these massive DilloImage related leaks. Can you please make sure that you are running the latest version of my img_ref patch (attached)? I add added prints to a_Image_new() and Image_free() and recorded them in a logfile. With the patch the numbers seem to match fine here. Cheers, Johannes
On Wed, Mar 11, 2009 at 02:10:21PM +0100, Hofmann Johannes wrote:
Hi Jeremy,
in your valgrind there are still these massive DilloImage related leaks.
My apologies, the version of your patch that I was using failed to apply after a recent pull so I dropped it and never got round to fixing it. So it's not been in my local Dillo for the past few days.
Can you please make sure that you are running the latest version of my img_ref patch (attached)?
I just merged it. Thanks very much! Regards, Jeremy Henty
On Wed, Mar 11, 2009 at 01:54:00PM +0000, Jeremy Henty wrote:
On Wed, Mar 11, 2009 at 02:10:21PM +0100, Hofmann Johannes wrote:
Hi Jeremy,
in your valgrind there are still these massive DilloImage related leaks.
My apologies, the version of your patch that I was using failed to apply after a recent pull so I dropped it and never got round to fixing it. So it's not been in my local Dillo for the past few days.
Can you please make sure that you are running the latest version of my img_ref patch (attached)?
I just merged it. Thanks very much!
Ah ok. Let's see if it helps. Cheers, Johannes
Hi Jeremy, in your valgrind logs I see references to "dList_truncate_free_data" which I can't find anywhere in the sources. Do you have some uncommitted patches in your tree? Cheers, Johannes
On Mon, Mar 16, 2009 at 07:18:14PM +0100, Hofmann Johannes wrote:
in your valgrind logs I see references to "dList_truncate_free_data" which I can't find anywhere in the sources. Do you have some uncommitted patches in your tree?
Yes, this is part of the dList_* API cleanup I talked about elsewhere. Unfortunately those patches are stuck in my (Mercurial) queue ahead of the BW_* flags cleanup patch, which has been submitted and not reviewed yet. I realise that it is unhelpful to anyone using my valgrind logs that my Dillo is so heavily patched at the moment. Would it help if I push the BW_* flags cleanup patch back up my queue and submit the dList_* API patches instead? They might be easier to review (as they are just refactorings) and once they were out of the way (whether accepted or rejected) the divergence between my Dillo and the mainstream would be small again. (BTW, there has always been some small divergence, but this is the first time there has been a persistent large divergence that has affected the valgrind logs.) Regards, Jeremy Henty
On Mon, Mar 16, 2009 at 09:36:20PM +0000, Jeremy Henty wrote:
On Mon, Mar 16, 2009 at 07:18:14PM +0100, Hofmann Johannes wrote:
in your valgrind logs I see references to "dList_truncate_free_data" which I can't find anywhere in the sources. Do you have some uncommitted patches in your tree?
Yes, this is part of the dList_* API cleanup I talked about elsewhere. Unfortunately those patches are stuck in my (Mercurial) queue ahead of the BW_* flags cleanup patch, which has been submitted and not reviewed yet.
I realise that it is unhelpful to anyone using my valgrind logs that my Dillo is so heavily patched at the moment. Would it help if I push the BW_* flags cleanup patch back up my queue and submit the dList_* API patches instead? They might be easier to review (as they are just refactorings) and once they were out of the way (whether accepted or rejected) the divergence between my Dillo and the mainstream would be small again. (BTW, there has always been some small divergence, but this is the first time there has been a persistent large divergence that has affected the valgrind logs.)
I'd like to fix as many valgrind errors as possible before the release. But it's pretty hard as I can't reproduce them myself. How long does it take you to get e.g. the image related leak messages? Are you doing anything special? Regards, Johannes
On Mon, Mar 16, 2009 at 10:49:41PM +0100, Hofmann Johannes wrote:
How long does it take you to get e.g. the image related leak messages?
Very hard to say. It never seems to happen after just a few minutes, but after a few hours it's pretty common.
Are you doing anything special?
Not that I can tell, just surfing lots. Regards, Jeremy Henty
On Sun, Feb 15, 2009 at 02:14:53AM +0000, Jeremy Henty wrote:
On Sat, Feb 14, 2009 at 07:04:21PM -0300, Jorge Arellano Cid wrote:
On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote:
Would having a single page with anchors for each link be enough, or do you want separate pages for each one?
A single page seems easier.
Actually, I've gone for a summary page with links to a separate page for each error. I've put some information from the stack traces into the link texts. I think it works rather well, eg. you can clearly see that most of the errors are coming from CSS handling (and some of those leaks are not as small as I thought). Please comment.
I just committed two fixes for CSS related leaks. Not sure if that's all. Regards, Johannes
participants (3)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org