- Dillo-dev - lists.mailman3.com

Splitting html.cc: common functions, part 1

by corvid＠lavabit.com

compiler errors: I think it's that Jeremy is using gcc3 and not seeing those errors.

June 6, 2008

Splitting html.cc: common functions, part 1

by jcid＠dillo.org

Hi Jeremy, On Thu, Jun 05, 2008 at 06:25:33PM +0100, Jeremy Henty wrote: > > This patch moves some function declarations from html.cc to > html_common.hh . It only does *some* of the renaming because the full > patch breaks the list's moderation limit. I'll follow up to this > message with the rest of the renaming. You may want to batch this > patch and the followup together as a single commit. > > Please comment! With regard to big patches and splitting, please don't burden yourself with splitting. This is just cleanup so please send me one big patch to my email address not dillo-dev. After applying thwe full patchset, I got compiler errors. :( <quote> g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I../../dw-testbed -I/usr/include/libpng12 -I/usr/local/include -I/usr/include/freetype2 -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -MT form.o -MD -MP -MF .deps/form.Tpo -c -o form.o form.cc form.cc: In member function 'void DilloHtmlInput::reset()': form.cc:1413: error: jump to case label form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1414: error: jump to case label form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1419: error: jump to case label form.cc:1415: error: crosses initialization of 'dw::core::ui::ToggleButtonResource* tb_r' form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1434: error: jump to case label form.cc:1415: error: crosses initialization of 'dw::core::ui::ToggleButtonResource* tb_r' form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1449: error: jump to case label [...] </quote> To solve this problem, please send me one big patch with all the changes. I'm not committing anything yet. -- Cheers Jorge.-

June 6, 2008

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