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.) I can't think of any other crashes, but I don't remember whether Johannes still gets bus errors.
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.)
I can't think of any other crashes, but I don't remember whether Johannes still gets bus errors.
No, they got fixed with http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-July/004649.html The only issues I'm seeing are the 128 tabs limit from fltk and the redraw storms related to the MenuTabPager. Cheers, Johannes
Johannes wrote:
On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote:
I can't think of any other crashes, but I don't remember whether Johannes still gets bus errors.
No, they got fixed with http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-July/004649.html
The only issues I'm seeing are the 128 tabs limit from fltk and the redraw storms related to the MenuTabPager.
Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C all segfault. I thought somebody said something (that I didn't pay attention to) about the file menu since tabs were added, but if so, I can't find that mail.
On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote:
Johannes wrote:
On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote:
I can't think of any other crashes, but I don't remember whether Johannes still gets bus errors.
No, they got fixed with http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-July/004649.html
The only issues I'm seeing are the 128 tabs limit from fltk and the redraw storms related to the MenuTabPager.
Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C all segfault. I thought somebody said something (that I didn't pay attention to) about the file menu since tabs were added, but if so, I can't find that mail.
Please check the patch in CVS. FLTK2 has a bug in that it regards the first menu item letter as a shortcut. Note: I tried with invisible shortcuts doing nothing, removing shortcuts and all that stuff, until I found this way to workaround the problem. Note2: Alt-W and Alt-X are accelerators, so they're OK. AFAIS there's no more segfault here. -- Cheers Jorge.-
Jorge wrote:
On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote:
Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C all segfault. I thought somebody said something (that I didn't pay attention to) about the file menu since tabs were added, but if so, I can't find that mail.
Please check the patch in CVS.
FLTK2 has a bug in that it regards the first menu item letter as a shortcut.
Note: I tried with invisible shortcuts doing nothing, removing shortcuts and all that stuff, until I found this way to workaround the problem.
Note2: Alt-W and Alt-X are accelerators, so they're OK.
AFAIS there's no more segfault here.
Alt-W and Alt-X still segfault for me. What's an accelerator?
On Mon, Sep 29, 2008 at 02:09:36PM +0000, corvid wrote:
Jorge wrote:
On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote:
Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C all segfault. I thought somebody said something (that I didn't pay attention to) about the file menu since tabs were added, but if so, I can't find that mail.
Please check the patch in CVS.
FLTK2 has a bug in that it regards the first menu item letter as a shortcut.
Note: I tried with invisible shortcuts doing nothing, removing shortcuts and all that stuff, until I found this way to workaround the problem.
Note2: Alt-W and Alt-X are accelerators, so they're OK.
AFAIS there's no more segfault here.
Alt-W and Alt-X still segfault for me.
Hmm... What fltk version are you using? Anyway, as a workaround, try removing the ampersand in the labels for "Close Window" and "Exit Dillo", in UI::make_menubar().
What's an accelerator?
Kind of a shortcut that you set with an ampersand in the label of an fltk::Item. Disclaimer: "accelerator" may not be the correct name for it. -- Cheers Jorge.-
Jorge wrote:
On Mon, Sep 29, 2008 at 02:09:36PM +0000, corvid wrote:
Jorge wrote:
On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote:
Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C all segfault. I thought somebody said something (that I didn't pay attention to) about the file menu since tabs were added, but if so, I can't find that mail.
Please check the patch in CVS.
FLTK2 has a bug in that it regards the first menu item letter as a shortcut.
Note: I tried with invisible shortcuts doing nothing, removing shortcuts and all that stuff, until I found this way to workaround the problem.
Note2: Alt-W and Alt-X are accelerators, so they're OK.
AFAIS there's no more segfault here.
Alt-W and Alt-X still segfault for me.
Hmm...
What fltk version are you using?
Anyway, as a workaround, try removing the ampersand in the labels for "Close Window" and "Exit Dillo", in UI::make_menubar().
The latest snapshot, 6305. Removing the ampersands == no more segfaults for me.
On Mon, Sep 29, 2008 at 05:49:44PM +0000, corvid wrote:
Jorge wrote:
On Mon, Sep 29, 2008 at 02:09:36PM +0000, corvid wrote:
Jorge wrote:
On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote:
Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C all segfault. I thought somebody said something (that I didn't pay attention to) about the file menu since tabs were added, but if so, I can't find that mail.
Please check the patch in CVS.
FLTK2 has a bug in that it regards the first menu item letter as a shortcut.
Note: I tried with invisible shortcuts doing nothing, removing shortcuts and all that stuff, until I found this way to workaround the problem.
Note2: Alt-W and Alt-X are accelerators, so they're OK.
AFAIS there's no more segfault here.
Alt-W and Alt-X still segfault for me.
Does anybody else see this bug?
Hmm...
What fltk version are you using?
Anyway, as a workaround, try removing the ampersand in the labels for "Close Window" and "Exit Dillo", in UI::make_menubar().
The latest snapshot, 6305.
Same here...
Removing the ampersands == no more segfaults for me.
Good, at least we have a workaround. -- Cheers Jorge.-
Jorge wrote:
On Mon, Sep 29, 2008 at 05:49:44PM +0000, corvid wrote:
Jorge wrote:
On Mon, Sep 29, 2008 at 02:09:36PM +0000, corvid wrote:
Jorge wrote:
On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote:
Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C all segfault. I thought somebody said something (that I didn't pay attention to) about the file menu since tabs were added, but if so, I can't find that mail.
Please check the patch in CVS.
FLTK2 has a bug in that it regards the first menu item letter as a shortcut.
Note: I tried with invisible shortcuts doing nothing, removing shortcuts and all that stuff, until I found this way to workaround the problem.
Note2: Alt-W and Alt-X are accelerators, so they're OK.
AFAIS there's no more segfault here.
Alt-W and Alt-X still segfault for me.
Does anybody else see this bug?
Here's the backtrace that I get: #0 0x080c9df0 in fltk::Widget::any_of (this=0x70, f=4864) at ../fltk/Widget.h:143 #1 0x080c9e3c in fltk::Widget::takesevents (this=0x70) at ../fltk/Widget.h:168 #2 0x080e43c4 in fltk::Widget::take_focus (this=0x70) at run.cxx:152 #3 0x080d6bc5 in fltk::MenuBar::handle (this=0x816a5a0, event=12) at MenuBar.cxx:94 #4 0x080ff1c3 in fltk::Widget::send (this=0x816a5a0, event=12) at Widget.cxx:804 #5 0x080c96d6 in fltk::Group::handle (this=0x816aa58, event=12) at Group.cxx:416 #6 0x080ff1c3 in fltk::Widget::send (this=0x816aa58, event=12) at Widget.cxx:804 #7 0x080c9691 in fltk::Group::handle (this=0x816a818, event=12) at Group.cxx:413 #8 0x080ff1c3 in fltk::Widget::send (this=0x816a818, event=12) at Widget.cxx:804 #9 0x080c9691 in fltk::Group::handle (this=0x815abb0, event=12) at Group.cxx:413 #10 0x080503e8 in UI::handle (this=0x815abb0, event=12) at ui.cc:809 #11 0x080ff1c3 in fltk::Widget::send (this=0x815abb0, event=12) at Widget.cxx:804 #12 0x080ef2ce in fltk::TabGroup::handle (this=0x815ab28, event=12) at TabGroup.cxx:239 #13 0x080567bf in CustTabGroup::handle (this=0x815ab28, e=12) at uicmd.cc:79 #14 0x080ff1c3 in fltk::Widget::send (this=0x815ab28, event=12) at Widget.cxx:804 #15 0x080c9691 in fltk::Group::handle (this=0x815a6a0, event=12) at Group.cxx:413 #16 0x0810160c in fltk::Window::handle () #17 0x080ff1c3 in fltk::Widget::send (this=0x815a6a0, event=12) at Widget.cxx:804 #18 0x080dfd11 in fltk::handle (event=12, window=0x815a6a0) at run.cxx:1319 #19 0x080dfdb9 in fltk::try_shortcut () at run.cxx:1195 #20 0x080d1167 in fltk::Input::handle_key () at Widget.cxx:49 #21 0x080d15d5 in fltk::Input::handle () at Widget.cxx:49 #22 0x080d18f1 in fltk::Input::handle () at Widget.cxx:49 #23 0x0805431c in CustInput::handle (this=0x81657f0, e=8) at ui.cc:82 #24 0x080ff1f2 in fltk::Widget::send (this=0x81657f0, event=8) at Widget.cxx:808 #25 0x080dfc4d in fltk::handle (event=8, window=0x815a6a0) at run.cxx:1293 #26 0x080e62a8 in fltk::handle () at x11/run.cxx:1961 #27 0x080e62f0 in do_queued_events () at x11/run.cxx:399 #28 0x080e661c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 #29 0x080e66b7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 #30 0x080e67ce in fltk::run () at run.cxx:399 #31 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127
I wrote:
Jorge wrote:
On Mon, Sep 29, 2008 at 05:49:44PM +0000, corvid wrote:
Jorge wrote:
On Mon, Sep 29, 2008 at 02:09:36PM +0000, corvid wrote:
Jorge wrote:
On Sun, Sep 28, 2008 at 12:52:47AM +0000, corvid wrote: > Playing with the file menu, I see that Alt-W, Alt-E, Alt-X, Alt-C > all segfault. I thought somebody said something (that I didn't pay > attention to) about the file menu since tabs were added, but if so, > I can't find that mail.
Please check the patch in CVS.
FLTK2 has a bug in that it regards the first menu item letter as a shortcut.
Note: I tried with invisible shortcuts doing nothing, removing shortcuts and all that stuff, until I found this way to workaround the problem.
Note2: Alt-W and Alt-X are accelerators, so they're OK.
AFAIS there's no more segfault here.
Alt-W and Alt-X still segfault for me.
Does anybody else see this bug?
Here's the backtrace that I get:
#0 0x080c9df0 in fltk::Widget::any_of (this=0x70, f=4864) at ../fltk/Widget.h:143 #1 0x080c9e3c in fltk::Widget::takesevents (this=0x70) at ../fltk/Widget.h:168 #2 0x080e43c4 in fltk::Widget::take_focus (this=0x70) at run.cxx:152 #3 0x080d6bc5 in fltk::MenuBar::handle (this=0x816a5a0, event=12) at MenuBar.cxx:94
[snip] MenuBar.cxx:93 went as follows: #0 a_UIcmd_close_bw (vbw=0x81b1958) at uicmd.cc:232 #1 0x08055bc9 in a_UIcmd_close_all_bw () at uicmd.cc:259 #2 0x08051c58 in menubar_cb (wid=0x8166288, data=0x810df5d) at ui.cc:477 #3 0x080d643a in fltk::Menu::popup () at Widget.cxx:49 #4 0x080d6cb9 in fltk::MenuBar::handle (this=0x816a440, event=12) at MenuBar.cxx:93 so MenuBar and its lastfocus_ are dead by line 94. There seems to be a pattern emerging lately :)
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.-
Jorge 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?
Seems to be working well so far. Is there any danger in adding something like a_Nav_cancel_expect to a_UIcmd_stop()? PS Stop should have a keyboard shortcut, I think. I long had a reflex of hitting ESC from the netscape/mozilla days, but of course ESC would be inconsistent for dillo.
On Sat, Sep 27, 2008 at 11:15:42PM +0000, corvid wrote:
Jorge 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?
Seems to be working well so far. Is there any danger in adding something like a_Nav_cancel_expect to a_UIcmd_stop()?
What's the idea behind it? If you want to get rid of empty cache entries from unsuccesful http connections, it's more complex than that. BTW, I plan to do that after the release.
PS Stop should have a keyboard shortcut, I think. I long had a reflex of hitting ESC from the netscape/mozilla days, but of course ESC would be inconsistent for dillo.
Could be. Maybe Ctrl-P. Although Stop is not yet doing exactly what it should. -- Cheers Jorge.-
Jorge wrote:
On Sat, Sep 27, 2008 at 11:15:42PM +0000, corvid wrote:
Jorge 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?
Seems to be working well so far. Is there any danger in adding something like a_Nav_cancel_expect to a_UIcmd_stop()?
What's the idea behind it?
If you want to get rid of empty cache entries from unsuccesful http connections, it's more complex than that. BTW, I plan to do that after the release.
I'm on page A. I try to go to page B, which seems to be taking a long time to think about resolving or contacting the host or whatever. I hit stop and go back to reading and want to continue loading images. Or if DNS couldn't resolve the hostname, I could hit stop to re-enable loading images.
On Sat, Sep 27, 2008 at 11:15:42PM +0000, corvid wrote:
Jorge 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?
Seems to be working well so far. Is there any danger in adding something like a_Nav_cancel_expect to a_UIcmd_stop()?
It looks safe to do. It even looks like the right thing to do. Just committed: - Disallowed loading images when expecting is set. - Added a cancel_expect call to the Stop button. -- Cheers Jorge.-
Jorge 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?
Now I've started to see a few times -- seemingly at random -- where I can't load an image unless I page back and forward again. I'll have to stick some MSGs in my tree and see why it's unhappy.
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). -- Cheers Jorge.-
Jorge wrote:
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).
Yes. Also, I found out why loading was sometimes randomly disabled (as mentioned yesterday). You know how leaving the window sometimes causes an extra Nav_open_url()? That was turning nav_expecting back on. The following patch has gotten rid of those for me:
On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote:
Jorge wrote:
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).
Yes.
Also, I found out why loading was sometimes randomly disabled (as mentioned yesterday). You know how leaving the window sometimes causes an extra Nav_open_url()?
No, I don't know. How is it triggered? -- Cheers Jorge.-
Jorge wrote:
On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote:
Also, I found out why loading was sometimes randomly disabled (as mentioned yesterday). You know how leaving the window sometimes causes an extra Nav_open_url()?
No, I don't know. How is it triggered?
Really? I've gotten them often throughout this whole fltk era. Taking out my fix, here's a breakpoint on Nav_open_url, triggered by leaving the window: Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 #7 0x080e56f4 in fix_focus () at run.cxx:108 #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 #12 0x080e79fe in fltk::run () at run.cxx:399 #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127
On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote:
Jorge wrote:
On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote:
Also, I found out why loading was sometimes randomly disabled (as mentioned yesterday). You know how leaving the window sometimes causes an extra Nav_open_url()?
No, I don't know. How is it triggered?
Really? I've gotten them often throughout this whole fltk era. Taking out my fix, here's a breakpoint on Nav_open_url, triggered by leaving the window:
Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 #7 0x080e56f4 in fix_focus () at run.cxx:108 #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 #12 0x080e79fe in fltk::run () at run.cxx:399 #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127
From the bt it's clear it happens, But how do I trigger/reproduce it. I've tried moving the mouse pointer out of the window, focusing another window, etc. With no luck. -- Cheers Jorge.-
Jorge wrote:
On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote:
Jorge wrote:
On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote:
Also, I found out why loading was sometimes randomly disabled (as mentioned yesterday). You know how leaving the window sometimes causes an extra Nav_open_url()?
No, I don't know. How is it triggered?
Really? I've gotten them often throughout this whole fltk era. Taking out my fix, here's a breakpoint on Nav_open_url, triggered by leaving the window:
Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 #7 0x080e56f4 in fix_focus () at run.cxx:108 #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 #12 0x080e79fe in fltk::run () at run.cxx:399 #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127
From the bt it's clear it happens, But how do I trigger/reproduce it. I've tried moving the mouse pointer out of the window, focusing another window, etc. With no luck.
The reliable way that I'm using (haven't checked how many of these steps/precautions are strictly necessary) - type an url into the Location CustInput and press enter. - don't touch the mouse - when the page has finished loading completely - move the mouse out of the window In case there's some WM interaction, I have fvwm.
On Wed, Oct 01, 2008 at 10:47:45PM +0000, corvid wrote:
Jorge wrote:
On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote:
Jorge wrote:
On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote:
Also, I found out why loading was sometimes randomly disabled (as mentioned yesterday). You know how leaving the window sometimes causes an extra Nav_open_url()?
No, I don't know. How is it triggered?
Really? I've gotten them often throughout this whole fltk era. Taking out my fix, here's a breakpoint on Nav_open_url, triggered by leaving the window:
Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 #7 0x080e56f4 in fix_focus () at run.cxx:108 #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 #12 0x080e79fe in fltk::run () at run.cxx:399 #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127
From the bt it's clear it happens, But how do I trigger/reproduce it. I've tried moving the mouse pointer out of the window, focusing another window, etc. With no luck.
The reliable way that I'm using (haven't checked how many of these steps/precautions are strictly necessary) - type an url into the Location CustInput and press enter. - don't touch the mouse - when the page has finished loading completely - move the mouse out of the window
In case there's some WM interaction, I have fvwm.
OK, I can see the bug with fvwm. Please check the CVS code. It solves the problem here. -- Cheers Jorge.-
Jorge wrote:
On Wed, Oct 01, 2008 at 10:47:45PM +0000, corvid wrote:
Jorge wrote:
On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote:
Jorge wrote:
On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote:
Also, I found out why loading was sometimes randomly disabled (as mentioned yesterday). You know how leaving the window sometimes causes an extra Nav_open_url()?
No, I don't know. How is it triggered?
Really? I've gotten them often throughout this whole fltk era. Taking out my fix, here's a breakpoint on Nav_open_url, triggered by leaving the window:
Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 #7 0x080e56f4 in fix_focus () at run.cxx:108 #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 #12 0x080e79fe in fltk::run () at run.cxx:399 #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127
From the bt it's clear it happens, But how do I trigger/reproduce it. I've tried moving the mouse pointer out of the window, focusing another window, etc. With no luck.
The reliable way that I'm using (haven't checked how many of these steps/precautions are strictly necessary) - type an url into the Location CustInput and press enter. - don't touch the mouse - when the page has finished loading completely - move the mouse out of the window
In case there's some WM interaction, I have fvwm.
OK, I can see the bug with fvwm.
Please check the CVS code. It solves the problem here.
It's working!
On Fri, Oct 03, 2008 at 06:32:50PM +0000, corvid wrote:
Jorge wrote:
On Wed, Oct 01, 2008 at 10:47:45PM +0000, corvid wrote:
Jorge wrote:
On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote:
Jorge wrote:
On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > Also, I found out why loading was sometimes randomly disabled (as mentioned > yesterday). You know how leaving the window sometimes causes an extra > Nav_open_url()?
No, I don't know. How is it triggered?
Really? I've gotten them often throughout this whole fltk era. Taking out my fix, here's a breakpoint on Nav_open_url, triggered by leaving the window:
Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 #7 0x080e56f4 in fix_focus () at run.cxx:108 #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 #12 0x080e79fe in fltk::run () at run.cxx:399 #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127
From the bt it's clear it happens, But how do I trigger/reproduce it. I've tried moving the mouse pointer out of the window, focusing another window, etc. With no luck.
The reliable way that I'm using (haven't checked how many of these steps/precautions are strictly necessary) - type an url into the Location CustInput and press enter. - don't touch the mouse - when the page has finished loading completely - move the mouse out of the window
In case there's some WM interaction, I have fvwm.
OK, I can see the bug with fvwm.
Please check the CVS code. It solves the problem here.
It's working!
Form inputs were also checked and FltkEntryResource::setText() calls value() which is a wrapper for text(). -- Cheers Jorge.-
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. Cheers, Johannes
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?
Update: This only seems to happen when fltk was compiled with the --disable-xft switch. Cheers, Johannes
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? -- Cheers Jorge.-
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 Cheers, Johannes
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! BTW, does a: - new_w = strlen(str)*8 + 20; + new_w = strlen(str)*8 + 40; in ui.cc solve the problem for you? If true, I can make a patch using measure(). -- Cheers Jorge.-
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?
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. Cheers, Johannes
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.-
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. Cheers, Johannes
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.-
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de