On Thu, Oct 02, 2008 at 04:50:55PM +0200, Johannes Hofmann wrote:
On Wed, Oct 01, 2008 at 07:21:35PM -0400, Jorge Arellano Cid wrote:
On Wed, Oct 01, 2008 at 11:11:23PM +0200, Johannes Hofmann wrote:
On Wed, Oct 01, 2008 at 03:01:19PM -0400, Jorge Arellano Cid wrote:
On Wed, Oct 01, 2008 at 06:14:47PM +0200, Johannes Hofmann wrote:
On Wed, Oct 01, 2008 at 11:45:53AM -0400, Jorge Arellano Cid wrote:
On Wed, Oct 01, 2008 at 04:47:05PM +0200, Johannes Hofmann wrote: > Hi, > > On Wed, Oct 01, 2008 at 10:33:20AM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > On Sat, Sep 27, 2008 at 05:38:03PM -0400, Jorge Arellano Cid wrote: > > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > > It's still possible to crash dillo if you click on a remote link and > > > > quickly click on some images to load them. Doesn't crash every time, > > > > but typically within four tries or so. I had assumed it was the same > > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > > > If I stick > > > > a_Bw_stop_clients(bw, BW_Img); > > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > > earlier today, so there's something wrong with just doing that. > > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > > > That message means big trouble: the event loop stepped over itself... > > > > > > I've tried several different ways but can't get to crash it. > > > > > > Does the attached patch help? > > > > > > -- > > > Cheers > > > Jorge.- > > > > > diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc > > > --- dillo2/src/html.cc 2008-09-27 15:11:08.000000000 -0400 > > > +++ dillo2-cur/src/html.cc 2008-09-27 17:34:21.000000000 -0400 > > > @@ -711,6 +711,8 @@ bool_t DilloHtml::unloadedImages() > > > */ > > > void DilloHtml::loadImages (const DilloUrl *pattern) > > > { > > > + dReturn_if_fail (bw->nav_expecting == FALSE); > > > + > > > for (int i = 0; i < images->size(); i++) { > > > if (images->get(i)->image) { > > > if ((!pattern) || (!a_Url_cmp(images->get(i)->url, pattern))) { > > > > Can you still crash dillo this way, with the latest CVS? > > (i.e. without the above patch). > > I'm currently seeing all sorts of crashes and I suspect that they > are related to xpmImage from fltk. > Could someone with a linux machine please check current dillo with > valgrind especially when the new mini_bug_xpm is shown? > > Also changing mini_bug_xpm to 15x15 seems to fix things for me. > I don't understand all that completely, but other crashes might be > related to this.
OK, I'll check with valgrind... Does changing mini_ok_xpm to 16x16 fix it too?
No it doesn't, that's what I thought first too :-)
But it really only happens when fltk was compiled with --disable-xft
I did that and FLTK's tests don't use xft, but my dillo-fltk still uses them!
Did you call ./configure for dillo again?
Yes. I forgot to make install FLTK, now it works. :)
BTW, does a:
- new_w = strlen(str)*8 + 20; + new_w = strlen(str)*8 + 40;
in ui.cc solve the problem for you?
No, it doesn't. I think it's a fltk problem.
Yes, valgrind reports an invalid write of size 1. See the attached file.
It looks like unless FLTK2 is patched, we'll have a w=15 minibug as workaround.
-- Cheers Jorge.-
==17533== Invalid write of size 1 ==17533== at 0x4893E4: argb32_converter(unsigned char const*, unsigned char*, int) (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) ==17533== by 0x4BA415: fltk::xpmImage::fetch(fltk::Image&, char const* const*) (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) ==17533== by 0x4BA45C: fltk::xpmImage::fetch() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) ==17533== by 0x488AFB: fltk::Image::fetch_if_needed() const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) ==17533== by 0x488B76: fltk::Image::_measure(int&, int&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) ==17533== by 0x4B85D9: fltk::Widget::draw_label(fltk::Rectangle const&, int) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) ==17533== by 0x47AA90: fltk::Button::draw(int) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) ==17533== by 0x48645A: fltk::Group::draw() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) ==17533== by 0x48645A: fltk::Group::draw() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk)
Thanks. I think I've found the problem. It's now in the fltk bugtracker: http://fltk.org/str.php?L2054 Let's hope the fix get's commited soon.
Excellent! Maybe you can write a note to fltk-dev so Bill S. notices quickly. -- Cheers Jorge.-