- Dillo-dev - lists.mailman3.com

[bug]: CSS image crash

by onepoint＠starurchin.org

Jeremy Henty wrote: > If you point dillo at http://www.youtube.com/user/zynaddsubfx and > scroll down then Dillo will crash before you get to the bottom. > [...] > > GDB shows that the drawing code is dereferencing a NULL FltkColor*: OK, StyleEngine::apply() in styleengine.cc sets border colors to NULL when the corresponding CSS property is transparent. Which seems OK. These are used by static functions drawBorder{Top,Left,Bottom,Right}() in dw/style.cc . These functions are clearly intended to handle NULL colors, eg. drawBorderTop() checks whether style->borderColor.top is NULL, and similarly for the others. The bug is that some of these functions may (depending on style->borderStyle) dereference other members of style->borderColor without checking whether they are NULL. In particular: *) drawBorderBottom() may reference style->borderColor.top *) drawBorderLeft() may reference style->borderColor.top So I guess the fix is to add extra guards to the code paths where other members of style->borderColor are referenced. I am puzzled by the lack of symmetry between these functions. Why do drawBorder{Bottom,Left}() sometimes use style->borderColor.top, yet drawBorder{Top,Right} only ever use their *own* color? (This is all specific to FLTK-2.0 .) Comments? Regards, Jeremy Henty

March 22, 2011

Main Dillo HG repository

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > I asked Andreas to fix it again (I messed with it twice) and now > it's fixed. Thanks to him. Excellent! Many thanks to Andreas! Regards, Jeremy Henty

March 22, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

Roger wrote: > > On Mon, Mar 21, 2011 at 10:30:33PM +0000, Jeremy Henty wrote: > > > >If you point dillo at http://www.youtube.com/user/zynaddsubfx and > >scroll down then Dillo will crash before you get to the bottom. I > >have attached a minimal test case that reproduces this (strangely, > >the empty SRC attribute on the img element is necessary). > > > >GDB shows that the drawing code is dereferencing a NULL FltkColor*: > > > > #0 0x080a4811 in dw::fltk::FltkViewBase::drawPolygon (this=0x49f4318, > > color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=true, > > points=0xbeae1a48, npoints=4) > > at /home/jeremy/.packages/dillo/HG/local/dw/fltkviewbase.cc:464 > > 464 setcolor(((FltkColor*)color)->colors[shading]); > > I see a segfault using fltk-1.3 as well here when viewing the above > URL. Interesting. What happens when you point the fltk-1.3 version at the test case I attached? I get an immediate crash with the fltk-2 version. > Although Dillo doesn't crash immediately when loading the page here, > seems to happen after scrolling all the way down the page and > shortly after starting to scroll upward. I think the crash happens only when the image with the offending style is actually displayed, which is why you have to scroll down the original page. It looks as though the bug is due to the style engine assigning a NULL color somewhere. Your backtrace shows the same thing as mine - FltkViewBase::drawPolygon() is called with a NULL color argument. This suggests that fixing the style engine will fix the crash for both versions. Who understands the style engine? Regards, Jeremy Henty

March 22, 2011

[bug]: CSS image crash

by rogerx.oss＠gmail.com

> On Mon, Mar 21, 2011 at 10:30:33PM +0000, Jeremy Henty wrote: > >If you point dillo at http://www.youtube.com/user/zynaddsubfx and >scroll down then Dillo will crash before you get to the bottom. I >have attached a minimal test case that reproduces this (strangely, the >empty SRC attribute on the img element is necessary). > >GDB shows that the drawing code is dereferencing a NULL FltkColor*: > > #0 0x080a4811 in dw::fltk::FltkViewBase::drawPolygon (this=0x49f4318, > color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=true, > points=0xbeae1a48, npoints=4) > at /home/jeremy/.packages/dillo/HG/local/dw/fltkviewbase.cc:464 > 464 setcolor(((FltkColor*)color)->colors[shading]); > >Regards, > >Jeremy Henty For what it's worth, here's my GDB session. --- Begin Snip --- Nav_open_url: new url='http://www.youtube.com/user/zynaddsubfx' a_Nav_expect_done: repush! Html_tag_open_link(): addCssUrl http://s.ytimg.com/yt/cssbin/www-core-vfll8nFx1.css Html_tag_open_link(): addCssUrl http://s.ytimg.com/yt/cssbin/www-the-rest-vflgCq-F2.css Html_tag_open_link(): addCssUrl http://s.ytimg.com/yt/cssbin/www-channel_new-vflebJ8FK.css no values for shorthand property 'border-color' no values for shorthand property 'border-color' no values for shorthand property 'border-color' DNS error: HOST_NOT_FOUND Dns_server [1]: i2.ytimg.com is (nil) [Thread 0xb7c2bb70 (LWP 5397) exited] Program received signal SIGSEGV, Segmentation fault. _______________________________________________________________________________ eax:441D7F20 ebx:00000004 ecx:00000000 edx:00000000 eflags:00010202 esi:0810D268 edi:BFFFDA00 esp:BFFFD930 ebp:BFFFD978 eip:080987F9 cs:0073 ds:007B es:007B fs:0000 gs:0033 ss:007B o d I t s z a p c [007B:BFFFD930]---------------------------------------------------------[stack] BFFFD960 : 60 4A 38 B7 60 59 2F 08 - E8 D9 FF BF 78 44 2F 08 `J8.`Y/.....xD/. BFFFD950 : 51 00 01 01 04 00 00 00 - 98 D9 FF BF 78 4D 2F 08 Q...........xM/. BFFFD940 : 40 AF 10 08 00 03 00 00 - C4 3B 14 08 50 D9 FF BF @........;..P... BFFFD930 : 94 E9 FF BF 60 57 10 08 - 58 D9 FF BF AF 4E D4 46 ....`W..X....N.F [007B:0810D268]---------------------------------------------------------[ data] 0810D268 : 28 2E 0C 08 E0 2E 0C 08 - 70 09 10 08 50 E8 15 44 (.......p...P..D 0810D278 : 00 00 00 00 00 00 00 00 - 75 00 00 00 FE 04 00 00 ........u....... [0073:080987F9]---------------------------------------------------------[ code] => 0x80987f9 <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+57>: mov 0xc(%edx,%ecx,4),%edx 0x80987fd <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+61>: mov (%eax),%ebx 0x80987ff <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+63>: mov %edx,0x4(%esp) 0x8098803 <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+67>: mov %eax,(%esp) 0x8098806 <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+70>: call *0x3c(%ebx) 0x8098809 <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+73>: cmpb $0x0,-0x25(%ebp) ------------------------------------------------------------------------------ 0x080987f9 in fl_color (this=0x810d268, color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=0x1, convex=0x1, points=0xbfffda00, npoints=0x4) at /usr/include/fltk-1.1/FL/fl_draw.H:61 61 inline void fl_color(Fl_Color c) {fl_graphics_driver->color(c); } // select indexed color gdb> bt #0 0x080987f9 in fl_color (this=0x810d268, color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=0x1, convex=0x1, points=0xbfffda00, npoints=0x4) at /usr/include/fltk-1.1/FL/fl_draw.H:61 #1 fl_color (this=0x810d268, color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=0x1, convex=0x1, points=0xbfffda00, npoints=0x4) at /usr/include/fltk-1.1/FL/fl_draw.H:63 #2 dw::fltk::FltkViewBase::drawPolygon (this=0x810d268, color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=0x1, convex=0x1, points=0xbfffda00, npoints=0x4) at fltkviewbase.cc:497 #3 0x080a4587 in drawBorderBottom (view=0x810d268, area=0xbfffda6c, x=0x7, y=0x456, width=0x2e, height=0x9, style=0x82f4478, inverse=0x0) at style.cc:559 #4 dw::core::style::drawBorder (view=0x810d268, area=0xbfffda6c, x=0x7, y=0x456, width=0x2e, height=0x9, style=0x82f4478, inverse=0x0) at style.cc:840 #5 0x080a7518 in dw::core::Widget::drawWidgetBox (this=0x82f42c0, view=0x810d268, area=0xbfffdb6c, inverse=0x0) at widget.cc:385 #6 0x0808efca in dw::Textblock::draw (this=0x82f42c0, view=0x810d268, area=0xbfffdb6c) at textblock.cc:1534 #7 0x0808d7f6 in dw::Textblock::drawLine (this=0x82f4120, line=0x82fb260, view=0x810d268, area=0xbfffdc0c) at textblock.cc:1416 #8 0x0808f09c in dw::Textblock::draw (this=0x82f4120, view=0x810d268, area=0xbfffdc0c) at textblock.cc:1543 #9 0x08089fab in dw::Table::draw (this=0xb7330d20, view=0x810d268, area=0xbfffdcbc) at table.cc:256 #10 0x0808d7f6 in dw::Textblock::drawLine (this=0xb730b618, line=0xb7331260, view=0x810d268, area=0xbfffdd5c) at textblock.cc:1416 #11 0x0808f09c in dw::Textblock::draw (this=0xb730b618, view=0x810d268, area=0xbfffdd5c) at textblock.cc:1543 #12 0x08089fab in dw::Table::draw (this=0xb7330960, view=0x810d268, area=0xbfffde0c) at table.cc:256 #13 0x0808d7f6 in dw::Textblock::drawLine (this=0xb730b848, line=0xb73d9db8, view=0x810d268, area=0xbfffdf0c) at textblock.cc:1416 #14 0x0808f09c in dw::Textblock::draw (this=0xb730b848, view=0x810d268, area=0xbfffdf0c) at textblock.cc:1543 #15 0x0808d7f6 in dw::Textblock::drawLine (this=0xb730bbd8, line=0xb734db58, view=0x810d268, area=0xbfffe00c) at textblock.cc:1416 #16 0x0808f09c in dw::Textblock::draw (this=0xb730bbd8, view=0x810d268, area=0xbfffe00c) at textblock.cc:1543 #17 0x0808d7f6 in dw::Textblock::drawLine (this=0xb730ba30, line=0xb73e60c8, view=0x810d268, area=0xbfffe10c) at textblock.cc:1416 #18 0x0808f09c in dw::Textblock::draw (this=0xb730ba30, view=0x810d268, area=0xbfffe10c) at textblock.cc:1543 #19 0x0808d7f6 in dw::Textblock::drawLine (this=0x82fa700, line=0x82faa3c, view=0x810d268, area=0xbfffe20c) at textblock.cc:1416 #20 0x0808f09c in dw::Textblock::draw (this=0x82fa700, view=0x810d268, area=0xbfffe20c) at textblock.cc:1543 --- End Snip --- -- Roger http://rogerx.freeshell.org/

March 22, 2011

[bug]: CSS image crash

by rogerx.oss＠gmail.com

> On Mon, Mar 21, 2011 at 10:30:33PM +0000, Jeremy Henty wrote: > >If you point dillo at http://www.youtube.com/user/zynaddsubfx and >scroll down then Dillo will crash before you get to the bottom. I >have attached a minimal test case that reproduces this (strangely, the >empty SRC attribute on the img element is necessary). > >GDB shows that the drawing code is dereferencing a NULL FltkColor*: > > #0 0x080a4811 in dw::fltk::FltkViewBase::drawPolygon (this=0x49f4318, > color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=true, > points=0xbeae1a48, npoints=4) > at /home/jeremy/.packages/dillo/HG/local/dw/fltkviewbase.cc:464 > 464 setcolor(((FltkColor*)color)->colors[shading]); > >Regards, I see a segfault using fltk-1.3 as well here when viewing the above URL. Although Dillo doesn't crash immediately when loading the page here, seems to happen after scrolling all the way down the page and shortly after starting to scroll upward. -- Roger http://rogerx.freeshell.org/

March 22, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

If you point dillo at http://www.youtube.com/user/zynaddsubfx and scroll down then Dillo will crash before you get to the bottom. I have attached a minimal test case that reproduces this (strangely, the empty SRC attribute on the img element is necessary). GDB shows that the drawing code is dereferencing a NULL FltkColor*: #0 0x080a4811 in dw::fltk::FltkViewBase::drawPolygon (this=0x49f4318, color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=true, points=0xbeae1a48, npoints=4) at /home/jeremy/.packages/dillo/HG/local/dw/fltkviewbase.cc:464 464 setcolor(((FltkColor*)color)->colors[shading]); Regards, Jeremy Henty

March 22, 2011

Test case for a possible fltk1.3 bug

by Johannes.Hofmann＠gmx.de

On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > > Hi there, > > > > Please help me with this one. > > > > Attached goes a small program that shows what may be a bug in > > fltk-1.3: > > > > * resize the window back and forth and both "Group 1" and > > "Group 2" keep their heights. OK here. > > * With a small window, hide "Group 2" and resize to a big > > window, then show "Group 2". It grew while hidden!? > > > > > > My doubts are: > > > > Is this intended or a bug? > > If not a bug, how is the desired behaviour suppossed to be > > implemented? > > > > > > I know an ugly way to workaround it (used with the findbar), > > but, if it's a bug, I'd prefer to have it fixed, and to keep > > the code clean. > > > > What do you think? > > Your test program shows even weirder behaviour with dwm here. > Initially the buttons are not visible and then scale in strange > ways. > I think this is because dwm is resizing the window as it is created. > > I suggest we don't use Fl_Pack and make our own solution. I will try > to get something running. Please check the attached modified version of your test program. Does the CustPack class solve your problem? Cheers, Johannes

March 21, 2011

Test case for a possible fltk1.3 bug

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > Hi there, > > Please help me with this one. > > Attached goes a small program that shows what may be a bug in > fltk-1.3: > > * resize the window back and forth and both "Group 1" and > "Group 2" keep their heights. OK here. > * With a small window, hide "Group 2" and resize to a big > window, then show "Group 2". It grew while hidden!? > > > My doubts are: > > Is this intended or a bug? > If not a bug, how is the desired behaviour suppossed to be > implemented? > > > I know an ugly way to workaround it (used with the findbar), > but, if it's a bug, I'd prefer to have it fixed, and to keep > the code clean. > > What do you think? Your test program shows even weirder behaviour with dwm here. Initially the buttons are not visible and then scale in strange ways. I think this is because dwm is resizing the window as it is created. I suggest we don't use Fl_Pack and make our own solution. I will try to get something running. Cheers, Johannes

March 21, 2011

Main Dillo HG repository

by jcid＠dillo.org

On Sat, Mar 19, 2011 at 07:44:26PM +0100, Johannes Hofmann wrote: > On Sat, Mar 19, 2011 at 01:11:22PM +0000, Jeremy Henty wrote: > > > > Has this been fixed? I have not been pulling from it because I didn't > > want the FLTK-1.3 code to land on me. > > No not yet. > BTW, you can always check with "hg incoming" what you would > get on a pull. I asked Andreas to fix it again (I messed with it twice) and now it's fixed. Thanks to him. -- Cheers Jorge.-

March 21, 2011

[bug]: '<META HTTP-EQUIV="Expires" CONTENT="-1">' => endless calls to Nav_open_url()

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > I got the attached bit of HTML from a broken RSS feed and it > > causes Dillo to thrash, endlessly calling Nav_open_url(). [...] > > To me, it looks like the refresh is responsible. Yes, you're right. (I don't know how I convinced myself otherwise - I was probably editing one copy of the file and testing another - <facepalm/>.) > Probably reads the 0.1 as 0 and does the same bad thing we usually > get when we have 0 and don't have a URL argument sending us > somewhere else... So the bug is that Html_tag_open_meta() does not check that it has found a URL before doing the redirect? Does the attached patch look sensible? (The patch is a little messy, but all it does is wrap the redirect code in a "if (*content) { ... }".) Regards, Jeremy Henty

March 21, 2011