June 2008 - Dillo-dev - lists.mailman3.com

Splitting html.cc: what next?
by onepoint＠starurchin.org June 21, 2008

June 21, 2008

Off the top of my head, some suggestions for more files that could usefully be split out from html.cc: - table.cc , handles <table> , <tr> , <td> , <th> - list.cc , handles <ul> , <ol> , <li> , <dl> , <dt> , <dd> - text.cc , handles , , , , <strike> - paragraph.cc , handles , <blockquote> , <center> , <address> - page.cc , handles <html> , <head> , <title> , <meta> , <body> Thoughts? Regards, Jeremy Henty

3 7

occasional bus errors
by Johannes.Hofmann＠gmx.de June 20, 2008

June 20, 2008

Hi is anyone else seeing these rare bus errors? This is not new and happens every now and then. I'm trying to track it down, but it would be helpful to have a method to reliably reproduce it. Cheers, Johannes BTW: It's currently the only type of crash I noticed. Program terminated with signal 10, Bus error. #0 0x28595b1a in ?? () (gdb) bt #0 0x28595b1a in ?? () #1 0x0808ec51 in ~DeepIterator (this=0x28565720) at iterator.cc:515 #2 0x08091dc8 in dw::core::SelectionState::resetSelection (this=0x2850a47c) at selection.cc:85 #3 0x08091e20 in dw::core::SelectionState::reset (this=0x2850a47c) at selection.cc:75 #4 0x08091809 in dw::core::Layout::removeWidget (this=0x2850a400) at layout.cc:167 #5 0x080970ff in ~Widget (this=0x285aaf00) at widget.cc:269 #6 0x0807d554 in ~Textblock (this=0x285aaf00) at textblock.cc:117 #7 0x080916c7 in dw::core::Layout::setWidget (this=0x2850a400, widget=0x285b0300) at layout.cc:175 #8 0x08056ddc in a_Web_dispatch_by_type (Type=0x285a4560 "text/html; charset=us-ascii", Web=0x285659c0, Call=0x285958d0, Data=0x285958d4) at web.cc:94 #9 0x08058583 in Cache_process_queue (entry=0x28582400) at cache.c:1042 #10 0x08058d3c in a_Cache_process_dbuf (Op=0, buf=0x2873c000 "HTTP/1.1 200 OK\r\nDate: Fri, 20 Jun 2008 15:51:22 GMT\r\nServer: Apache/1.3.34 (Debian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.9.8c\r\nCache-control: no-cache\r\nConnection: close\r\nTransfer-Encoding: chu"..., buf_size=1440, Url=0x285a1d00) at cache.c:871 #11 0x080564b8 in a_Chain_fcb (Op=134802368, Info=0x285a2e80, Data1=0x285c9ac0, Data2=0x80eb3e3) at chain.c:111 #12 0x080743dc in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x28595b40, Data1=0x285c9200, Data2=0x0) at dpi.c:223 #13 0x080564b8 in a_Chain_fcb (Op=134802368, Info=0x285a2e80, Data1=0x285c9200, Data2=0x0) at chain.c:111 #14 0x08074cfd in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x28595ba0, Data1=0x28595e00, Data2=0x0) at IO.c:418 #15 0x08074e8a in IO_callback (fd=<value optimized out>, io=0x28595e00) at IO.c:205 #16 0x08074f63 in IO_fd_read_cb (fd=4, data=0x20e) at IO.c:291 #17 0x080c28cd in fltk::wait () #18 0x080c2a7d in fltk::run () #19 0x0804e63d in main (argc=-1958539068, argv=0x58390446) at dillo.cc:125

4 4

[patch] move highlighting data into Textblock
by Johannes.Hofmann＠gmx.de June 20, 2008

June 20, 2008

Hi, as promised here comes a patch to move highlighting information from struct Word into Textblock to save memory. I had to change the semantics of the highlighting API slightly (see comments) to ensure that the highlighted part is always contiguous. Here are some measurements (with load_images=NO): Page dillo-fltk patched_dillo-fltk dillo1 firefox ============================================================== splash 7240K 7236K xslt [1] 15016K 14220K freebsd [2] 70264K 58084K mysql [3] 186M 148M 232M 200M Obviously the difference is mostly visible on large pages. And firefox is pretty close regarding memory usage. However it needed more than 3 minutes to load the local mysql page compared to 6 seconds for dillo-fltk! Please look out for possible highlight related regressions. Cheers, Johannes [1] http://www.w3.org/TR/xslt [2] http://www.freebsd.org/doc/en/books/handbook/book.html [3] http://downloads.mysql.com/docs/refman-6.0-en.html.tar.gz

3 8

easy way to get many root certificates?
by corvid＠lavabit.com June 20, 2008

June 20, 2008

I'm tired of clicking on the "remote certificate cannot be verified" message. I added a couple of lines to https.c so that it would save certificates. When I encountered the next https page, "openssl x509 -text -in [certificate]" showed that Equifax was the issuer. I got their root certificate, stuck it in .dillo/certs, found the hash value with "openssl x509 -hash -in [certificate]", and linked it to [hash].0. And, hey, no more message! But I don't want to do that over and over for all of the common root certificates. It seems that you can get the certificates out of firefox if you have some program called certutil, but, so far as I can tell, this requires getting a bunch of mozilla code known as NSS that is something like six megs of source. This is nowhere near worth the headaches that would surely result from trying to compile such a thing. So, does anyone happen to know an easy and convenient way to deal with this?

3 5

[patch] fix FltkPlatform destructor
by Johannes.Hofmann＠gmx.de June 19, 2008

June 19, 2008

Hi, this fixes a small memory leak in FltkPlatform. Johannes

2 1

recent style/layout segfaults
by corvid＠lavabit.com June 18, 2008

June 18, 2008

I've seen occasional segfaults in recent weeks, and twice now I've been able to catch them when I remembered to have gdb going (and, well, zero times when I remembered to have ulimit -c unlimited) These two have been nearly identical. Here's the one I just got: #0 0x00000048 in ?? () #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, attrs=0x81dfc08) at layout.hh:253 #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, layout=0x815ca58) at style.cc:287 #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, layout=0x815ca58) at style.hh:587 #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) at style.hh:505 #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, widget=0x827b3b0) at layout.cc:175 #8 0x0805aea8 in a_Web_dispatch_by_type ( Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, Data=0x821d324) at web.cc:94 .. The layout in frame 3 was: p *layout $7 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x814c0f0, views = 0x815cb78, topLevel = 0x0, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 0, canvasAscent = 0, canvasDescent = 0, usesViewport = true, scrollX = 0, scrollY = 0, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x815cba0, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x815ca58, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 1, toChar = 1, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 3, link = 0x0, linkChar = 3, linkNumber = 13}, findtextState = {key = 0x0, caseSens = 32, nexttab = 0x0, widget = 0x0, iterator = 0x0, hlIterator = 0x0}} and the layout in frame 7 was: p *this $8 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x8281808, views = 0x8246f38, topLevel = 0x8249308, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 665, canvasAscent = 5, canvasDescent = 11564, usesViewport = true, scrollX = 0, scrollY = 8854, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x81e4078, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x822f868, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 3, toChar = 3, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 136509888, link = 0x0, linkChar = 136509920, linkNumber = 0}, findtextState = { key = 0x0, caseSens = 16, nexttab = 0x0, widget = 0x8249308, iterator = 0x0, hlIterator = 0x0}} Both look fairly layoutish. I only had one bw open at the time of crash. My guess at the problem: StyleTable will give you back whatever Style matches your attrs, but maybe that Style was created with a different layout.

3 11

patch: view gzipped local files
by corvid＠lavabit.com June 18, 2008

June 18, 2008

I'd been considering this for a while, but couldn't decide whether it had any real value. Then it occurred to me that if people are often using dillo as a local document viewer for minimalist systems, they may value the ability to compress those documents.

2 1

About the patch for Style-related crashes: +1 !
by onepoint＠starurchin.org June 18, 2008

June 18, 2008

It's gone a little quiet here, I hope everyone's OK! Anyway I just want to register a yes vote for the patch that was proposed last week to fix crashes from inside Style::unref() when closing windows. These crashes were making Dillo almost unusable for me, but I applied the patch on Sunday and life has been blissful ever since. (I sound like one of those awful TV ads, don't I?) The plan was to wait a week for comments before deciding. I hope it gets committed soon because a fix for these crashes is IMHO vital. Regards, Jeremy Henty

1 0

Valgrind: hashing StyleAttr objects accesses uninitialized data
by onepoint＠starurchin.org June 13, 2008

June 13, 2008

Ever since StyleAttr objects were cached in a hash to promote sharing, valgrind has reported nearly 1000 branches dependent on uninitialised data when dillo renders the splash page. These all come from StyleAttrs::hashValue() and StyleAttrs::equals() : if I hack hashValue() to return ((intptr_t) this) and equals() to return (this == otherAttrs) then the warnings disappear. Is this a problem? If these methods are accessing uninitialised data members then what happens when that data is initialised? The return values of hashValue() and equals() could change, which sounds like a potential source of bugs. Even if it's not a bug, if the value of hashValue() is unpredictable then we might not be sharing StyleAttr objects as much as we could and so we could be wasting memory. If it is correct to have code that raises these warnings, perhaps there could be a "#define VALGRIND" switch so developers could easily compile a dillo that doesn't raise them? (It's possible to silence them with a valgrind suppression file but that is tedious and risks hiding other warnings. It would be much more straightforward to have a valgrind-clean version of the code.) Comments are welcome, Jeremy Henty

3 6

form.cc: refactor DilloHtmlForm::eventHandler()
by onepoint＠starurchin.org June 11, 2008

June 11, 2008

Three small patches that clean up form event handling: 1: refactor file loading into DilloHtmlInput::readFile() 2: refactor form submission into DilloHtmlForm::submit() 3: refactor the input logic into DilloHtmlInput::activate() Regards, Jeremy Henty

2 1