- Dillo-dev - lists.mailman3.com

Leaking image structures

by Johannes.Hofmann＠gmx.de

On Wed, Feb 04, 2009 at 02:47:51PM +0000, Jeremy Henty wrote: > > One of the biggest leaks that valgrind reports is image structures. > I'm attaching logs that show memory being allocated by a_Png_new() and > cousins and not being freed. There are also frequent leaks of memory > allocated by the image libraries from within the various image > callbacks, but I suspect these are just another effect of the Dillo > image structures not being freed. > > Unfortunately I'm having a hard time tracking these leaks down. They > regularly appear after long browsing sessions, but I haven't found any > single page that reproduces them. I suspect they are caused by some > race condition inside the CCC rather than the HTML parser. I am > browsing with image loading enabled, and if I understand the code > correctly that means that the Web structures in the CCC own all the > references to image structures. > > The fact that image structures are reference counted makes it hard to > know when the structures should be freed anyway. Indeed, does Dillo > even ensure that image structures are freed? Maybe this is just a > symptom of incomplete cleanup at exit rather than a true leak? > > I've looked over the code and can't see any obvious leaks so I'm > rather stuck. Any tips for tracking this down? Even if it's not a > true leak it would be good to have a fix that cleaned up the valgrind > logs. I guess there is a leak when image loading is off. In that case images are not put in the html->images list and therefore not unrefed when leaving the page. Can you please try attached patch with valgrind and image loading on and off. Regards, Johannes

Feb. 17, 2009

Fun with autocnf and mercurial

by joerg.sonnenberger＠web.de

On Tue, Feb 17, 2009 at 05:54:17PM +0000, Jeremy Henty wrote: > On Tue, Feb 17, 2009 at 06:40:01PM +0100, Joerg Sonnenberger wrote: > > > Please ensure that this is not part of releases and/or if the .hg > > directory is missing. > > It already does this. If you are not in a Mercurial repository (or if > Mercurial is not installed) then the "if hg id ..." test fails and HG > is #defined to 0 instead of 1. The extra logging code is wrapped in a > "#if HG" so it will be removed by the preprocessor. I just tested > this by temporarily renaming .hg and rebuilding and it worked as > intended. Point is, release build should never differ whether hg is installed or not. I know that hg does the check internally, but that also depends on that no other hg binary can be found. Joerg

Feb. 17, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

On Tue, Feb 17, 2009 at 06:40:01PM +0100, Joerg Sonnenberger wrote: > Please ensure that this is not part of releases and/or if the .hg > directory is missing. It already does this. If you are not in a Mercurial repository (or if Mercurial is not installed) then the "if hg id ..." test fails and HG is #defined to 0 instead of 1. The extra logging code is wrapped in a "#if HG" so it will be removed by the preprocessor. I just tested this by temporarily renaming .hg and rebuilding and it worked as intended. Regards, Jeremy Henty

Feb. 17, 2009

Fun with autocnf and mercurial

by joerg.sonnenberger＠web.de

On Tue, Feb 17, 2009 at 05:26:36PM +0000, Jeremy Henty wrote: > Yes, that's much better. Revised patch attached. Please ensure that this is not part of releases and/or if the .hg directory is missing. Joerg

Feb. 17, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

On Tue, Feb 17, 2009 at 05:26:29PM +0100, Hofmann Johannes wrote: > I like the idea, but wouldn't something like "hg id" be more > appropriate? It shows the current revision which is not necessarily > tip. Yes, that's much better. Revised patch attached. Regards, Jeremy Henty

Feb. 17, 2009

Fun with autocnf and mercurial

by Johannes.Hofmann＠gmx.de

On Mon, Feb 16, 2009 at 11:09:21PM +0000, Jeremy Henty wrote: > > Here's a patch for discussion. Since I am parsing Dillo logs for > debugging, I thought it would be neat if Dillo logged the mercurial > revision. Patch attached. > > Thoughts? Does anyone know a better way to get the revision for a > particular tag? Piping "hg tags" through a sed script is rather > kludgy but I can't find a way to get mercurial to tell me directly. I like the idea, but wouldn't something like "hg id" be more appropriate? It shows the current revision which is not necessarily tip. Cheers, Johannes

Feb. 17, 2009

Leaking image structures

by corvid＠lavabit.com

I wrote: > Probably not related, but occasionally progressive jpegs > haven't been displaying some of the later scans. It does this when the image is being scaled.

Feb. 17, 2009

META charset without MIME type

by corvid＠lavabit.com

Jorge wrote: > I also want to maybe re-use this widget for the XHTML parsing > dilemma. This is: to render or not to render XHTML. Last time I > read the specs, XHTML must be validated and not rendered when not > valid. In practice, when facing non-valid XHTML, Firefox renders > it and doesn't even warn. If we render, and warn, and show the > BUGs found in the bug-meter, we'd be closer to the original idea. From a little reading, I get the impression that it has to be well-formed in an xml sense to be rendered, but you can have HTMLish errors like, oh, putting random things in <select> and still render it.

Feb. 17, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

Here's a patch for discussion. Since I am parsing Dillo logs for debugging, I thought it would be neat if Dillo logged the mercurial revision. Patch attached. Thoughts? Does anyone know a better way to get the revision for a particular tag? Piping "hg tags" through a sed script is rather kludgy but I can't find a way to get mercurial to tell me directly. I log the qparent revision as well as the tip revision because I manage patches with Mercurial queues, so my qparent revision is the vanilla tip revision that I am currently based on. Also, I used printf() to log the revisions because neither MSG nor MSG_WARN produced anything. I don't know why. Can anyone explain? Regards, Jeremy Henty

Feb. 17, 2009

META charset without MIME type

by corvid＠lavabit.com

Jorge wrote: > Don't worry man. This is more or less cooked. > > From the link suggested by Rogut?s Sparnuotos: > > http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G110.html > > I got to: > > http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H76.html > > which is a W3C's page with an example that uses quotes. Ergo, > we will support it. Not parsing the major/minor part because the quotes confused us, though? The type could differ -- I remember that crash Jeremy found where meta changed it to application/xhtml+xml...

Feb. 16, 2009