- Dillo-dev - lists.mailman3.com

Splitting html.cc: the rest of the form code

by onepoint＠starurchin.org

This is it!. These three patches complete the migration of all the form code to form.cc . They move respectively the receiver class, the input class and the class declarations (which were temporarily put in form.hh ). Now all the details of form handling are in form.cc and form.hh exports an opaque API to the rest of the Html module. Regards, Jeremy Henty

June 6, 2008

Splitting html.cc: the form class, part II

by onepoint＠starurchin.org

And here we move the rest of the DilloHtmlForm implementation, in two patches. The first patch moves the methods that create data for submitting a form. This is large because it includes a number of static functions that have to be moved together. The second patch moves the last method. Regards, Jeremy Henty

June 6, 2008

Splitting html.cc: the form class, part I

by onepoint＠starurchin.org

The next task is to move the implementation of DilloHtmlForm into form.cc . This is a lot of code, so I'm splitting it into several parts. This part moves the constructor, destructor and most of the methods. Regards, Jeremy Henty

June 6, 2008

recent style/layout segfaults

by corvid＠lavabit.com

Johannes wrote: > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > 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) > > I had some of these segfaults too. > > > 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 [snip] > > 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. > > > > I will have a look at that. Maybe the StyleTable should be > associated with a layout too. It looks like style uses layout to get to platform. I wonder whether it would go against any dw rules to let style have platform.

June 6, 2008

another segfault

by Johannes.Hofmann＠gmx.de

Hi, here is another segfault I get consistently when clicking a certain sequence of links. I have no idea about the cause however. Cheers, Johannes Loaded symbols for /usr/libexec/ld-elf.so.2 Core was generated by `dillo-fltk'. Program terminated with signal 11, Segmentation fault. #0 Html_get_attr2 (html=0x28560300, tag=0x284810a5 <Address 0x284810a5 out of bounds>, tagsize=70, attrname=0x80e9e69 "id", tag_parsing_flags=3) at html.cc:5707 5707 if (isspace(tag[i])) (gdb) bt #0 Html_get_attr2 (html=0x28560300, tag=0x284810a5 <Address 0x284810a5 out of bounds>, tagsize=70, attrname=0x80e9e69 "id", tag_parsing_flags=3) at html.cc:5707 #1 0x080617d5 in Html_write_raw (html=0x28560300, buf=0x28481000 <Address 0x28481000 out of bounds>, bufsize=1119, Eof=0) at html.cc:5628 #2 0x08061acd in DilloHtml::write (this=0x28560300, Buf=0x28481000 <Address 0x28481000 out of bounds>, BufSize=0, Eof=0) at html.cc:961 #3 0x08062196 in Html_callback (Op=0, Client=0x284f8fa0) at html.cc:5855 #4 0x08058433 in Cache_process_queue (entry=0x28474d40) at cache.c:1075 #5 0x08058d98 in a_Cache_process_dbuf (Op=0, buf=0x2854a000 "HTTP/1.1 200 OK\r\nDate: Thu, 05 Jun 2008 20:56:16 GMT\r\nServer: Apache/1.3.34 (Debian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.9.8c\r\nLast-Modified: Thu, 05 Jun 2008 16:16:48 GMT\r\nETag: \"271005-41b5-4"..., buf_size=1440, Url=0x284f9c00) at cache.c:871 #6 0x0805650c in a_Chain_fcb (Op=0, Info=0x2850f340, Data1=0x2850f230, Data2=0x80eb382) at chain.c:111 #7 0x08074444 in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x284f8f40, Data1=0x284f73c0, Data2=0x0) at dpi.c:223 #8 0x0805650c in a_Chain_fcb (Op=0, Info=0x2850f340, Data1=0x284f73c0, Data2=0x0) at chain.c:111 #9 0x08074d65 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x284f8f60, Data1=0x284f8f80, Data2=0x0) at IO.c:418 #10 0x08074ef2 in IO_callback (fd=<value optimized out>, io=0x284f8f80) at IO.c:205 #11 0x08074fcb in IO_fd_read_cb (fd=6, data=0xc) at IO.c:291 #12 0x080c286d in fltk::wait () #13 0x080c2a1d in fltk::run () #14 0x0804e63d in main (argc=Cannot access memory at address 0x0

June 5, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

Hi, On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > 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) I had some of these segfaults too. > > 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. > I will have a look at that. Maybe the StyleTable should be associated with a layout too. Cheers, Johannes

June 5, 2008

Splitting html.cc: form parsing *II*

by onepoint＠starurchin.org

These patches move the rest of the form parsing code into form.cc . Regards, Jeremy Henty

June 5, 2008

Splitting html.cc: form parsing I

by onepoint＠starurchin.org

Now we move the form parsing code into form.cc . The 40K posting limit forces me send the patches in two batches. Here's the first lot. Jeremy Henty

June 5, 2008

Splitting html.cc: moving stuff into the form source

by onepoint＠starurchin.org

These patches move some declarations into form.hh and the form API into form.cc . Note that the form class declarations will move into form.cc later, for now they must be in form.hh . Regards, Jeremy Henty

June 5, 2008

recent style/layout segfaults

by corvid＠lavabit.com

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.

June 5, 2008