- Dillo-dev - lists.mailman3.com

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

Splitting html.cc: common functions, part *2*

by onepoint＠starurchin.org

The rest of the renaming. Jeremy Henty

June 5, 2008

Splitting html.cc: common functions, part 1

by onepoint＠starurchin.org

<headslap> Here's the patch. The followup to *this* will complete the renaming. Jeremy Henty

June 5, 2008

Splitting html.cc: common functions, part 1

by onepoint＠starurchin.org

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! Jeremy Henty

June 5, 2008

Re: Splitting html.cc

by jcid＠dillo.org

On Thu, Jun 05, 2008 at 03:48:53PM +0100, Jeremy Henty wrote: > On Thu, Jun 05, 2008 at 09:02:28AM -0400, Jorge Arellano Cid wrote: > > On Wed, Jun 04, 2008 at 03:38:38PM +0100, Jeremy Henty wrote: > > > > > The next step is to move some of the function declarations across, > > > but that depends on deciding what to do with the function names. > > > Should I rename "Html_*" to "a_Html_*"? > > > > I'd prefer to have C functions called from other sources as > > a_Html_*. > > OK, but how does that rule apply to Html_tag_{open,close}_*() ? They > aren't explicitly called anywhere, They are called by the parser from inside html.cc. > just referenced from the Tags array > in html.cc . The split will move some of them into form.cc . It > would be ugly to rename some of them but not others. If the plan is > to move most or all of them to separate files like form.cc (which I > think would be a good way to split up html.cc) then perhaps we should > rename them all to a_Html_tag_{open,close}_*() in advance? As the Html_tag_{open,close}_*() functions are closely related to the parser, I'd prefer to have them not renamed. If there's a need, these functions could call a_Form_*() functions. Something like: Html_open_form () { [...] a_Form_do_something() [...] } -- Cheers Jorge.-

June 5, 2008