January 2009 - Dillo-dev - lists.mailman3.com

FreeHG performance

by onepoint＠starurchin.org

Am I the only one getting very poor performance from FreeHG ? Quite often I get a 404 Not Found and right now it's hanging. Everyone confirms that Mercurial itself is really fast and I've seen other reports criticising FreeHG's performance. Perhaps we should think about moving host? It's not always easy to find time to devote to Dillo so it's rather aggravating when that time is wasted just waiting for a connection to the server. I'm committed enough to grit my teeth and wait but I can see it putting off would-be contributors. Just a thought, Jeremy Henty

Jan. 30, 2009

Still leaking CSS values

by Johannes.Hofmann＠gmx.de

On Thu, Jan 29, 2009 at 06:34:22PM +0000, Jeremy Henty wrote: > > The "0123456789" value in the stylesheet leaks. Test case and > valgrind log attached. Should be fixed in tip now. It turned out to be a bug in the CSS parser. While tracking this down, I found a simple way to reduce the number of CSS rules (by eliminating those that have an empty property list). Regards, Johannes

Jan. 30, 2009

Still leaking CSS values

by onepoint＠starurchin.org

The "0123456789" value in the stylesheet leaks. Test case and valgrind log attached. Regards, Jeremy Henty

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by onepoint＠starurchin.org

On Thu, Jan 29, 2009 at 04:08:12PM +0100, Hofmann Johannes wrote: > Never mind. I think I've got it. See attached patch. That did it! That is, it removed the "definitely lost" errors. The "indirectly lost errors" are still there. I'm still not sure how to interpret them. They could be artifacts of the other leaks that I am currently suppressing. Attached the log and the test HTML I was using. Jeremy Henty

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by jcid＠dillo.org

On Thu, Jan 29, 2009 at 03:40:28PM +0100, Hofmann Johannes wrote: > On Thu, Jan 29, 2009 at 11:38:34AM -0300, Jorge Arellano Cid wrote: > > On Thu, Jan 29, 2009 at 02:33:30PM +0100, Hofmann Johannes wrote: > > > On Thu, Jan 29, 2009 at 09:37:31AM -0300, Jorge Arellano Cid wrote: > > > > On Wed, Jan 28, 2009 at 10:44:11PM +0100, Hofmann Johannes wrote: > > > > > On Wed, Jan 28, 2009 at 01:06:51PM +0000, Jeremy Henty wrote: > > > > > > On Tue, Jan 27, 2009 at 09:08:56AM +0100, Hofmann Johannes wrote: > > > > > > > On Tue, Jan 27, 2009 at 07:45:42AM +0000, Jeremy Henty wrote: > > > > > > > > I thought the problem was that CssPropertyList::set() does not > > > > > > > > free any existing value but I'm not sure I understand how these > > > > > > > > classes are meant to manage their memory. > > > > > > > > > > > > > > CSS values are stored in CssProperty::Value, which is a union. The > > > > > > > fix is to free Value.strVal, whenever Value contains a strVal (and > > > > > > > not an enum or length). To know this we could depend on the > > > > > > > corresponding CssProperty::Name (freeing it for > > > > > > > CSS_PROPERTY_FONT_FAMILY, but not for others), or add a Type member. > > > > > > > The latter is cleaner and would not need more memory, as Name and > > > > > > > Type could fit in two shorts. > > > > > > > > > > > > So, which should it be? I favour the former as I think that if we > > > > > > want to keep the Value struct lean then it is nicer to do it by not > > > > > > adding fields rather than resorting to packing tricks. But that's > > > > > > only a mild preference: either seems OK. > > > > > > > > > > Went with the former for now, but we will need to switch to the > > > > > latter to support "inherit" or properties that can hold strings _or_ > > > > > enums. > > > > > Please check current tip. > > > > > > > > These patches produce lots of warnings in the test directory: > > > > > > I can't reproduce the warnings, > > > > I'm using: > > gcc version 4.3.2 > > CFLAGS="-g -O0 -W" CXXFLAGS="-g -O0 -W" ./configure --enable-ssl > > > > > but I think I know the reason. It's > > > changeset 9a7684395cca. > > > Can you please check attached patch which tries to fix the > > > underlying issue in an other way. > > > Comments are welcome! We could also backout > > > 9a7684395cca and leave things as they were before, but deleting > > > memory allocated with strdup() is a bug. > > > > Yes, that's a bug. > > > > I think the solution is much simpler. The attached patch, > > applied on current tip, solves the issue. Please try it and > > commit if you like it. ;) > > Right. It's really not worth the effort to avoid this cast. > > Committed! Good. BTW, when receiving spare patches, after applying them and testing, this command comes very handy to commit: hg ci -u <User Info> e.g. hg ci -u "corvid <corvid(a)lavabit.com>" -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by Johannes.Hofmann＠gmx.de

On Thu, Jan 29, 2009 at 03:52:45PM +0100, Hofmann Johannes wrote: > On Thu, Jan 29, 2009 at 02:48:54PM +0000, Jeremy Henty wrote: > > On Thu, Jan 29, 2009 at 02:54:23PM +0100, Hofmann Johannes wrote: > > > Next try. Please check attached patch. > > > > No difference. :-( > > Does this also happen if you just start dillo with the > splash screen and quit again (without accessing any websites)? > Or which websites do you access to reproduce this? Never mind. I think I've got it. See attached patch. Cheers, Johannes

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by Johannes.Hofmann＠gmx.de

On Thu, Jan 29, 2009 at 02:48:54PM +0000, Jeremy Henty wrote: > On Thu, Jan 29, 2009 at 02:54:23PM +0100, Hofmann Johannes wrote: > > Next try. Please check attached patch. > > No difference. :-( Does this also happen if you just start dillo with the splash screen and quit again (without accessing any websites)? Or which websites do you access to reproduce this? Johannes

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by onepoint＠starurchin.org

On Thu, Jan 29, 2009 at 02:54:23PM +0100, Hofmann Johannes wrote: > Next try. Please check attached patch. No difference. :-( Jeremy Henty

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by Johannes.Hofmann＠gmx.de

On Thu, Jan 29, 2009 at 11:38:34AM -0300, Jorge Arellano Cid wrote: > On Thu, Jan 29, 2009 at 02:33:30PM +0100, Hofmann Johannes wrote: > > On Thu, Jan 29, 2009 at 09:37:31AM -0300, Jorge Arellano Cid wrote: > > > On Wed, Jan 28, 2009 at 10:44:11PM +0100, Hofmann Johannes wrote: > > > > On Wed, Jan 28, 2009 at 01:06:51PM +0000, Jeremy Henty wrote: > > > > > On Tue, Jan 27, 2009 at 09:08:56AM +0100, Hofmann Johannes wrote: > > > > > > On Tue, Jan 27, 2009 at 07:45:42AM +0000, Jeremy Henty wrote: > > > > > > > I thought the problem was that CssPropertyList::set() does not > > > > > > > free any existing value but I'm not sure I understand how these > > > > > > > classes are meant to manage their memory. > > > > > > > > > > > > CSS values are stored in CssProperty::Value, which is a union. The > > > > > > fix is to free Value.strVal, whenever Value contains a strVal (and > > > > > > not an enum or length). To know this we could depend on the > > > > > > corresponding CssProperty::Name (freeing it for > > > > > > CSS_PROPERTY_FONT_FAMILY, but not for others), or add a Type member. > > > > > > The latter is cleaner and would not need more memory, as Name and > > > > > > Type could fit in two shorts. > > > > > > > > > > So, which should it be? I favour the former as I think that if we > > > > > want to keep the Value struct lean then it is nicer to do it by not > > > > > adding fields rather than resorting to packing tricks. But that's > > > > > only a mild preference: either seems OK. > > > > > > > > Went with the former for now, but we will need to switch to the > > > > latter to support "inherit" or properties that can hold strings _or_ > > > > enums. > > > > Please check current tip. > > > > > > These patches produce lots of warnings in the test directory: > > > > I can't reproduce the warnings, > > I'm using: > gcc version 4.3.2 > CFLAGS="-g -O0 -W" CXXFLAGS="-g -O0 -W" ./configure --enable-ssl > > > but I think I know the reason. It's > > changeset 9a7684395cca. > > Can you please check attached patch which tries to fix the > > underlying issue in an other way. > > Comments are welcome! We could also backout > > 9a7684395cca and leave things as they were before, but deleting > > memory allocated with strdup() is a bug. > > Yes, that's a bug. > > I think the solution is much simpler. The attached patch, > applied on current tip, solves the issue. Please try it and > commit if you like it. ;) Right. It's really not worth the effort to avoid this cast. Committed! Thanks, Johannes

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by jcid＠dillo.org

On Thu, Jan 29, 2009 at 02:33:30PM +0100, Hofmann Johannes wrote: > On Thu, Jan 29, 2009 at 09:37:31AM -0300, Jorge Arellano Cid wrote: > > On Wed, Jan 28, 2009 at 10:44:11PM +0100, Hofmann Johannes wrote: > > > On Wed, Jan 28, 2009 at 01:06:51PM +0000, Jeremy Henty wrote: > > > > On Tue, Jan 27, 2009 at 09:08:56AM +0100, Hofmann Johannes wrote: > > > > > On Tue, Jan 27, 2009 at 07:45:42AM +0000, Jeremy Henty wrote: > > > > > > I thought the problem was that CssPropertyList::set() does not > > > > > > free any existing value but I'm not sure I understand how these > > > > > > classes are meant to manage their memory. > > > > > > > > > > CSS values are stored in CssProperty::Value, which is a union. The > > > > > fix is to free Value.strVal, whenever Value contains a strVal (and > > > > > not an enum or length). To know this we could depend on the > > > > > corresponding CssProperty::Name (freeing it for > > > > > CSS_PROPERTY_FONT_FAMILY, but not for others), or add a Type member. > > > > > The latter is cleaner and would not need more memory, as Name and > > > > > Type could fit in two shorts. > > > > > > > > So, which should it be? I favour the former as I think that if we > > > > want to keep the Value struct lean then it is nicer to do it by not > > > > adding fields rather than resorting to packing tricks. But that's > > > > only a mild preference: either seems OK. > > > > > > Went with the former for now, but we will need to switch to the > > > latter to support "inherit" or properties that can hold strings _or_ > > > enums. > > > Please check current tip. > > > > These patches produce lots of warnings in the test directory: > > I can't reproduce the warnings, I'm using: gcc version 4.3.2 CFLAGS="-g -O0 -W" CXXFLAGS="-g -O0 -W" ./configure --enable-ssl > but I think I know the reason. It's > changeset 9a7684395cca. > Can you please check attached patch which tries to fix the > underlying issue in an other way. > Comments are welcome! We could also backout > 9a7684395cca and leave things as they were before, but deleting > memory allocated with strdup() is a bug. Yes, that's a bug. I think the solution is much simpler. The attached patch, applied on current tip, solves the issue. Please try it and commit if you like it. ;) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 29, 2009