Hello, when I go to e.g. www.google.com enter a search, click submit and then when the result page shows up hit Enter, I always get a segfault: Program received signal SIGSEGV, Segmentation fault. loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 93 inline Iterator iterator() { Iterator it(createIterator()); return it; } (gdb) bt #0 loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 #1 0x08084367 in dw::core::ui::Resource::ActivateEmitter::emitActivate ( this=0x28661208, resource=0x28661200) at ui.cc:109 #2 0x080909d3 in fltk::Widget::do_callback (this=0x28661280) at Widget.h:125 #3 0x080ab6d1 in fltk::Input::handle_key (this=0x28661280) at Input.cxx:1267 #4 0x080abe42 in fltk::Input::handle (this=0x28661280, event=8, r=@0xbfbff414) at Input.cxx:1469 #5 0x080ac66b in fltk::Input::handle (this=0x28661280, event=8) at Input.cxx:1384 #6 0x080dfac2 in fltk::Widget::send (this=0x28661280, event=8) at Widget.cxx:805 #7 0x080be6dd in fltk::handle (event=8, window=0x28540000) at run.cxx:1287 #8 0x080c4bf4 in fltk::handle () at run.cxx:1947 #9 0x080c4c38 in do_queued_events () at run.cxx:396 #10 0x080c4f52 in fl_wait (time_to_wait=1.00000002e+20) at run.cxx:456 #11 0x080c4fed in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:457 #12 0x080c5104 in fltk::run () at run.cxx:393 #13 0x0804e714 in main (argc=Error accessing memory address 0x0: Bad address. ) at dillo.cc:107 I think it has to do with the input form of the previous page somehow still being activ. Jorge, do you know what happens to the fltk widgets like buttons or inputs, when a new page gets loaded? Are the deleted, and if so where in the code does this happen? Cheers, Johannes
Johannes wrote:
when I go to e.g. www.google.com enter a search, click submit and then when the result page shows up hit Enter, I always get a segfault:
It might not be the same problem, and I don't know whether it's a reasonable fix, but I used to have a lot of trouble with forms crashing until I did the following: diff -pur dw2/dw/fltkui.cc dw2-cur/dw/fltkui.cc --- dw2/dw/fltkui.cc 2007-10-06 22:03:01.000000000 +0000 +++ dw2-cur/dw/fltkui.cc 2007-11-04 01:46:01.000000000 +0000 @@ -40,6 +40,7 @@ #include <fltk/Symbol.h> #include <fltk/Item.h> #include <fltk/ItemGroup.h> +#include <fltk/events.h> namespace dw { namespace fltk { @@ -467,7 +468,8 @@ void FltkEntryResource::widgetCallback ( void *data) { printf ("when = %d\n", widget->when ()); - if (widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) + if ((widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) && + (::fltk::event_key() == ::fltk::ReturnKey)) ((FltkEntryResource*)data)->emitActivate (); }
On Thu, Nov 08, 2007 at 07:01:40PM +0000, place wrote:
Johannes wrote:
when I go to e.g. www.google.com enter a search, click submit and then when the result page shows up hit Enter, I always get a segfault:
It might not be the same problem, and I don't know whether it's a reasonable fix, but I used to have a lot of trouble with forms crashing until I did the following:
diff -pur dw2/dw/fltkui.cc dw2-cur/dw/fltkui.cc --- dw2/dw/fltkui.cc 2007-10-06 22:03:01.000000000 +0000 +++ dw2-cur/dw/fltkui.cc 2007-11-04 01:46:01.000000000 +0000 @@ -40,6 +40,7 @@ #include <fltk/Symbol.h> #include <fltk/Item.h> #include <fltk/ItemGroup.h> +#include <fltk/events.h>
namespace dw { namespace fltk { @@ -467,7 +468,8 @@ void FltkEntryResource::widgetCallback ( void *data) { printf ("when = %d\n", widget->when ()); - if (widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) + if ((widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) && + (::fltk::event_key() == ::fltk::ReturnKey)) ((FltkEntryResource*)data)->emitActivate (); }
I didn't remember why I made it long ago for ui.cc, fortunately some testing showed the reason. Patch committed with the following comment: /* The (::fltk::event_key() == ::fltk::ReturnKey) test * is necessary because WHEN_ENTER_KEY also includes * other events we're not interested in. For instance pressing * The Back or Forward, buttons, or the first click on a rendered * page. BUG: this must be investigated and reported to FLTK2 team */ -- Cheers Jorge.-
Hi, On Thu, Nov 08, 2007 at 06:49:36PM +0100, Johannes Hofmann wrote:
Hello,
when I go to e.g. www.google.com enter a search, click submit and then when the result page shows up hit Enter, I always get a segfault:
Yes, it happens here too.
Program received signal SIGSEGV, Segmentation fault. loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 93 inline Iterator iterator() { Iterator it(createIterator()); return it; } (gdb) bt #0 loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 #1 0x08084367 in dw::core::ui::Resource::ActivateEmitter::emitActivate ( this=0x28661208, resource=0x28661200) at ui.cc:109 #2 0x080909d3 in fltk::Widget::do_callback (this=0x28661280) at Widget.h:125 #3 0x080ab6d1 in fltk::Input::handle_key (this=0x28661280) at Input.cxx:1267 #4 0x080abe42 in fltk::Input::handle (this=0x28661280, event=8, r=@0xbfbff414) [...]
I think it has to do with the input form of the previous page somehow still being activ.
Me too. As a side effect of flickering, I noticed several times how some non existent inputs (text entries and buttons) were phantom-rendered during updates (i.e. appeared on screen for a few jiffies). I'm investigating. More later.
Jorge, do you know what happens to the fltk widgets like buttons or inputs, when a new page gets loaded?
They should be deleted, but my guess is that they don't.
Are the deleted, and if so where in the code does this happen?
I should hapen from: a_Web_dispatch_by_type /* This method frees the old dw if any */ layout->setWidget(dw); -- Cheers Jorge.-
Hi, On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote:
Hi,
On Thu, Nov 08, 2007 at 06:49:36PM +0100, Johannes Hofmann wrote:
Hello,
when I go to e.g. www.google.com enter a search, click submit and then when the result page shows up hit Enter, I always get a segfault:
Yes, it happens here too.
I think it has to do with the input form of the previous page somehow still being activ.
Me too.
As a side effect of flickering, I noticed several times how some non existent inputs (text entries and buttons) were phantom-rendered during updates (i.e. appeared on screen for a few jiffies).
I'm investigating. More later.
For instance, enable flickering (disable double-buffer and internal buffer), then go to: 1. www.google.com //and then to 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ While loading the second URL you'll see the phantom-rendering of the text input and the two buttons that google uses. Now, I thought this was to be deleted from the call in web.cc (as a children of the top widget or something), but there's another way to do it that looks like the original idea. In html parsing we have a structure called the linkblock. This contains all the data that is needed after the page is parsed and rendered (mainly forms data), and also dw widgets! In html.hh you'll find DilloHtmlLB. Within DilloHtmlLB there's a vector of DilloHtmlForm, which has a vector of DilloHtmlInput which holds widgets. The linkblock is designed to be freed when the displayed dw is deleted, but this hook is not currently operative! (this is the warning you get at html.cc compile time about Html_lb_free not being called). A few days ago we were working on another issue with "place", and I made the necessary bindings for freeing the analog of DilloHtmlLB when parsing plain text. This is why when you leave a plain text page in dillo to render another one (anything) you'll see a message like this: a_Plain_free! 0x8177860 Now, making the binding for html.cc is not hard but takes some time and "place" is about to send it to me soon. But, maybe I understood it wrong:
[Jorge wrote] BTW, I asked on the linkblock/callback patch, because if I look at it, you can devote your time to gzip decoding.
[place wrote] All right.
:-) So maybe this means he's expecting me to do it. Place, would you mind confirm? Anyway, when the linkblock-free callback is hooked, those widgets can be destroyed from Html_lb_free(). Which is mainly implemented but not yet tested. Hope this helps. -- Cheers Jorge.-
[Jorge wrote] BTW, I asked on the linkblock/callback patch, because if I look at it, you can devote your time to gzip decoding.
[place wrote] All right.
:-)
So maybe this means he's expecting me to do it.
Place, would you mind confirm?
Yes, I thought you were doing it... What I had meant about page url and base_url was that I'd started, screwed it up badly, and happily scrapped it when I saw your message.
On Fri, Nov 09, 2007 at 01:15:19PM +0000, place wrote:
[Jorge wrote] BTW, I asked on the linkblock/callback patch, because if I look at it, you can devote your time to gzip decoding.
[place wrote] All right.
:-)
So maybe this means he's expecting me to do it.
Place, would you mind confirm?
Yes, I thought you were doing it...
What I had meant about page url and base_url was that I'd started, screwed it up badly, and happily scrapped it when I saw your message.
Good. I'll make it ASAP then and let Johannes know so we can solve the forms problem too. -- Cheers Jorge.-
Hi, The big patch for html.cc getting rid of the linkblock and html structures, merging them in a single class with link-receiver inside, and also enabling freeing of the resources formerly stored in the linkblock, is commited! :-) The amazing thing is that it seems to work. ;) On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote:
Hi,
On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote:
[...] As a side effect of flickering, I noticed several times how some non existent inputs (text entries and buttons) were phantom-rendered during updates (i.e. appeared on screen for a few jiffies).
[...]
For instance, enable flickering (disable double-buffer and internal buffer), then go to:
1. www.google.com //and then to 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/
While loading the second URL you'll see the phantom-rendering of the text input and the two buttons that google uses.
Although now we have memory-freeing hooked, the phantom rendering still occurs...
Now, I thought this was to be deleted from the call in web.cc (as a children of the top widget or something), but there's another way to do it that looks like the original idea.
Actually, it doesn't look like a good idea. What seems proper is that Dw internally deletes its widget tree, and DilloHtml deletes its non-dw state (as now).
In html parsing we have a structure called the linkblock. This contains all the data that is needed after the page is parsed and rendered (mainly forms data), and also dw widgets!
In html.hh you'll find DilloHtmlLB. Within DilloHtmlLB there's a vector of DilloHtmlForm, which has a vector of DilloHtmlInput which holds widgets.
The linkblock is designed to be freed when the displayed dw is deleted, but this hook is not currently operative! (this is the warning you get at html.cc compile time about Html_lb_free not being called).
Well, now there's no linkblock, and everything is inside the DilloHtml class (much cleaner). Memory handling is hooked and it works.
Anyway, when the linkblock-free callback is hooked, those widgets can be destroyed from Html_lb_free(). Which is mainly implemented but not yet tested.
My mistake: this part is for freeing non-dw data. What _seems_ to happen is that the "Embed" widgets are not being deleted (not yet confirmed though). Feel free to investigate! :-) -- Cheers Jorge.-
Hi Jorge, On Sat, Nov 10, 2007 at 07:15:59PM -0300, Jorge Arellano Cid wrote:
Hi,
The big patch for html.cc getting rid of the linkblock and html structures, merging them in a single class with link-receiver inside, and also enabling freeing of the resources formerly stored in the linkblock, is commited! :-)
The amazing thing is that it seems to work. ;)
Wow, that's a huge cleanup!
On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote:
Hi,
On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote:
[...] As a side effect of flickering, I noticed several times how some non existent inputs (text entries and buttons) were phantom-rendered during updates (i.e. appeared on screen for a few jiffies).
[...]
For instance, enable flickering (disable double-buffer and internal buffer), then go to:
1. www.google.com //and then to 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/
While loading the second URL you'll see the phantom-rendering of the text input and the two buttons that google uses.
Although now we have memory-freeing hooked, the phantom rendering still occurs...
Yes, maybe it has to do with how dillo widgets must be deleted. There was recently a discussion about this in the fltk forums. I will try to figure out what happens. But at the moment I get various sorts of crashes with this patch immediately when I load a page with forms. Here are two stacks, but I don't think they are very useful. Program received signal SIGBUS, Bus error. 0x08097a03 in split ( str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, W=95, flags=262656, getwidth=0x80a39a6 <fltk::getwidth(char const*, int)>) at drawtext.cxx:493 493 if (!*p || *p == '\n') { (gdb) bt #0 0x08097a03 in split ( str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, W=95, flags=262656, getwidth=0x80a39a6 <fltk::getwidth(char const*, int)>) at drawtext.cxx:493 #1 0x08097c74 in fltk::drawtext ( textfunction=0x80a3756 <fltk::drawtext_transformed(char const*, int, float, float)>, getwidth=0x80a39a6 <fltk::getwidth(char const*, int)>, str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, r=@0xbfbff288, flags=262656) at drawtext.cxx:571 #2 0x08098296 in fltk::drawtext ( str=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, r1=@0xbfbff348, flags=262656) at drawtext.cxx:544 #3 0x080e38af in fltk::LabelType::draw (this=0x8127b14, label=0x28807f70 '?' <repeats 144 times> <Error reading address 0x28808000: Bad address>, r=@0xbfbff348, flags=262656) at Widget_draw.cxx:58 #4 0x080e3575 in fltk::Widget::draw_label (this=0x2878ecc0, ir=@0xbfbff40c, flags=262656) at Widget_draw.cxx:234 #5 0x08094089 in fltk::Button::draw (this=0x2878ecc0, glyph_width=0) at Button.cxx:237 #6 0x080940df in fltk::Button::draw (this=0x2878ecc0) at Button.cxx:247 #7 0x080a4441 in fltk::Group::draw_child (this=0x284efc04, w=@0x2878ecc0) at Group.cxx:750 #8 0x080a4634 in fltk::Group::draw (this=0x284efc04) at Group.cxx:682 #9 0x0807ebad in dw::fltk::FltkViewBase::draw (this=0x284efc00) at fltkviewbase.cc:53 #10 0x0807c560 in dw::fltk::FltkViewport::draw_area (data=0x284efc00, cr=@0xbfbff5a0) at fltkviewport.cc:164 #11 0x0807c67f in dw::fltk::FltkViewport::draw (this=0x284efc00) at fltkviewport.cc:189 #12 0x080a4319 in fltk::Group::update_child (this=0x284f1c00, w=@0x284efc04) at Group.cxx:769 #13 0x080a46d6 in fltk::Group::draw (this=0x284f1c00) at Group.cxx:697 #14 0x080e4d14 in fltk::Window::draw (this=0x284f1c00) at Window.cxx:80 #15 0x080c228e in fltk::Window::flush (this=0x284f1c00) at run.cxx:2611 #16 0x080c1366 in fl_window_flush (window=0x284f1c00) at run.cxx:651 #17 0x080c13e6 in fltk::flush () at run.cxx:685 #18 0x080c7708 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:480 #19 0x080c7758 in fltk::run () at run.cxx:393 #20 0x0804e6d4 in main (argc=Error accessing memory address 0x40200: Bad address. ) at dillo.cc:107 dillo-fltk in realloc(): error: junk pointer, too high to make sense Program received signal SIGABRT, Aborted. 0x2838863c in kill () from /usr/lib/libc.so.6 (gdb) bt #0 0x2838863c in kill () from /usr/lib/libc.so.6 #1 0x283d6bc9 in abort () from /usr/lib/libc.so.6 #2 0x283a49a2 in reallocf () from /usr/lib/libc.so.6 #3 0x283a49d9 in reallocf () from /usr/lib/libc.so.6 #4 0x283a6420 in realloc () from /usr/lib/libc.so.6 #5 0x08068ad9 in dRealloc (mem=0xd0d0d0d0, size=676212922) at dlib.c:44 #6 0x08068d6d in dStr_resize (ds=0x284e3400, n_sz=676212922, keep=Variable "keep" is not available. ) at dlib.c:189 #7 0x08068db7 in dStr_vsprintfa (ds=0x284e3400, format=0x80f8d8c "the required DOCTYPE declaration is missing (or invalid)\n", argp=0xbfbfd348 "??????\005\bB\205\002") at dlib.c:361 #8 0x0805a5cc in Html_msg (html=0x28535b00, format=0x80f8d8c "the required DOCTYPE declaration is missing (or invalid)\n") at html.cc:176 #9 0x0805f8f2 in Html_write_raw (html=0x28535b00, buf=0x28519000 "<html><head><meta http-equiv=\"content-type\" content=\"text/html; charset=ISO-8859-1\"><title>Google</title><style>body,td,a,p,.h{font-family:arial,sans-serif}.h{font-size:20px}.h{color:#3366cc}.q{color:"..., bufsize=1122, Eof=0) at html.cc:4645 #10 0x0805fac5 in DilloHtml::write (this=0x28535b00, Buf=0x28519000 "<html><head><meta http-equiv=\"content-type\" content=\"text/html; charset=ISO-8859-1\"><title>Google</title><style>body,td,a,p,.h{font-family:arial,sans-serif}.h{font-size:20px}.h{color:#3366cc}.q{color:"..., BufSize=1122, Eof=0) at html.cc:649 #11 0x0805fb3e in Html_callback (Op=0, Client=0x28548900) at html.cc:4971 #12 0x08057032 in Cache_process_queue (entry=0x2853bda0) at cache.c:802 #13 0x08055732 in a_Chain_fcb (Op=2, Info=0x2850cec0, Data1=0x28542d40, Data2=0x80f824e) at chain.c:86 #14 0x0806b1aa in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x2850cec0, Data1=0x28542ea0, Data2=0x0) at dpi.c:224 #15 0x08055732 in a_Chain_fcb (Op=2, Info=0x2850c040, Data1=0x28542ea0, Data2=0x0) at chain.c:86 #16 0x0806b925 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x2850c040, Data1=0x285487a0, Data2=0x0) at IO.c:398 #17 0x0806bb26 in IO_callback (fd=Variable "fd" is not available. ) at IO.c:190 #18 0x0806bbf3 in IO_fd_read_cb (fd=6, data=0x4) at IO.c:269 #19 0x080c75a6 in fl_wait (time_to_wait=1.00000002e+20) at run.cxx:456 #20 0x080c7641 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:457 #21 0x080c7758 in fltk::run () at run.cxx:393 I will try to run in with valgrind when I have access to a Linux machine. Cheers, Johannes
On Sun, Nov 11, 2007 at 02:22:39PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Sat, Nov 10, 2007 at 07:15:59PM -0300, Jorge Arellano Cid wrote:
Hi,
The big patch for html.cc getting rid of the linkblock and html structures, merging them in a single class with link-receiver inside, and also enabling freeing of the resources formerly stored in the linkblock, is commited! :-)
The amazing thing is that it seems to work. ;)
Wow, that's a huge cleanup!
Yes it was! 8-P
On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote:
Hi,
On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote:
[...] As a side effect of flickering, I noticed several times how some non existent inputs (text entries and buttons) were phantom-rendered during updates (i.e. appeared on screen for a few jiffies).
[...]
For instance, enable flickering (disable double-buffer and internal buffer), then go to:
1. www.google.com //and then to 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/
While loading the second URL you'll see the phantom-rendering of the text input and the two buttons that google uses.
Although now we have memory-freeing hooked, the phantom rendering still occurs...
Yes, maybe it has to do with how dillo widgets must be deleted. There was recently a discussion about this in the fltk forums. I will try to figure out what happens. But at the moment I get various sorts of crashes with this patch immediately when I load a page with forms.
Here it doesn't crash, but it's sure the phantom widgets are referencing freed memory (it get garbage labels). You can comment: dw->setDeleteCallback(a_Html_free, this); and test as it was before the patch (with no memory freeing). -- Cheers Jorge.-
Hi Jorge, On Sun, Nov 11, 2007 at 03:58:43PM -0300, Jorge Arellano Cid wrote:
On Sun, Nov 11, 2007 at 02:22:39PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Sat, Nov 10, 2007 at 07:15:59PM -0300, Jorge Arellano Cid wrote:
Hi,
The big patch for html.cc getting rid of the linkblock and html structures, merging them in a single class with link-receiver inside, and also enabling freeing of the resources formerly stored in the linkblock, is commited! :-)
The amazing thing is that it seems to work. ;)
Wow, that's a huge cleanup!
Yes it was! 8-P
On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote:
Hi,
On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote:
[...] As a side effect of flickering, I noticed several times how some non existent inputs (text entries and buttons) were phantom-rendered during updates (i.e. appeared on screen for a few jiffies).
[...]
For instance, enable flickering (disable double-buffer and internal buffer), then go to:
1. www.google.com //and then to 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/
While loading the second URL you'll see the phantom-rendering of the text input and the two buttons that google uses.
Although now we have memory-freeing hooked, the phantom rendering still occurs...
Yes, maybe it has to do with how dillo widgets must be deleted. There was recently a discussion about this in the fltk forums. I will try to figure out what happens. But at the moment I get various sorts of crashes with this patch immediately when I load a page with forms.
Here it doesn't crash, but it's sure the phantom widgets are referencing freed memory (it get garbage labels).
You can comment:
dw->setDeleteCallback(a_Html_free, this);
and test as it was before the patch (with no memory freeing).
just a short update on this issue. There seems to be something more fundamentally wrong on my system. #include "../dlib.h" int main (char **argv, int argc) { Dstr *ds = dStr_new(""); dStr_sprintfa(ds, "Hello %s", "foo"); dStr_sprintfa(ds, "World %d", 42); } crashes here, but it runs fine on Linux and even valgrind does not complain on Linux. Johannes
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Mon, Nov 12, 2007 at 05:56:36PM +0100, Johannes Hofmann wrote:
On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote:
Hi,
On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote:
[...] As a side effect of flickering, I noticed several times how some non existent inputs (text entries and buttons) were phantom-rendered during updates (i.e. appeared on screen for a few jiffies).
[...]
For instance, enable flickering (disable double-buffer and internal buffer), then go to:
1. www.google.com //and then to 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/
While loading the second URL you'll see the phantom-rendering of the text input and the two buttons that google uses.
Although now we have memory-freeing hooked, the phantom rendering still occurs...
Yes, maybe it has to do with how dillo widgets must be deleted. There was recently a discussion about this in the fltk forums. I will try to figure out what happens. But at the moment I get various sorts of crashes with this patch immediately when I load a page with forms.
Here it doesn't crash, but it's sure the phantom widgets are referencing freed memory (it get garbage labels).
You can comment:
dw->setDeleteCallback(a_Html_free, this);
and test as it was before the patch (with no memory freeing).
just a short update on this issue. There seems to be something more fundamentally wrong on my system.
#include "../dlib.h"
int main (char **argv, int argc) { Dstr *ds = dStr_new("");
dStr_sprintfa(ds, "Hello %s", "foo"); dStr_sprintfa(ds, "World %d", 42); }
crashes here, but it runs fine on Linux and even valgrind does not complain on Linux.
If vsnprintf(), when called alone, works on your system, try adding the extra: va_copy(argp2, argp); to dStr_sprintfa() as in dStr_vsprintfa(). Just an idea. -- Cheers Jorge.-
On Mon, Nov 12, 2007 at 04:13:49PM -0300, Jorge Arellano Cid wrote:
On Mon, Nov 12, 2007 at 05:56:36PM +0100, Johannes Hofmann wrote:
On Fri, Nov 09, 2007 at 09:34:33AM -0300, Jorge Arellano Cid wrote:
Hi,
On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > [...] > As a side effect of flickering, I noticed several times how some > non existent inputs (text entries and buttons) were phantom-rendered > during updates (i.e. appeared on screen for a few jiffies). > > [...]
For instance, enable flickering (disable double-buffer and internal buffer), then go to:
1. www.google.com //and then to 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/
While loading the second URL you'll see the phantom-rendering of the text input and the two buttons that google uses.
Although now we have memory-freeing hooked, the phantom rendering still occurs...
Yes, maybe it has to do with how dillo widgets must be deleted. There was recently a discussion about this in the fltk forums. I will try to figure out what happens. But at the moment I get various sorts of crashes with this patch immediately when I load a page with forms.
Here it doesn't crash, but it's sure the phantom widgets are referencing freed memory (it get garbage labels).
You can comment:
dw->setDeleteCallback(a_Html_free, this);
and test as it was before the patch (with no memory freeing).
just a short update on this issue. There seems to be something more fundamentally wrong on my system.
#include "../dlib.h"
int main (char **argv, int argc) { Dstr *ds = dStr_new("");
dStr_sprintfa(ds, "Hello %s", "foo"); dStr_sprintfa(ds, "World %d", 42); }
crashes here, but it runs fine on Linux and even valgrind does not complain on Linux.
If vsnprintf(), when called alone, works on your system, try adding the extra:
va_copy(argp2, argp);
to dStr_sprintfa() as in dStr_vsprintfa().
Just an idea.
Thanks, but I think the culprit is a weird bug when libc was compiled with a special gcc-version. Anyway, I now have a system again on which current dillo-fltk runs pretty stable. So I can now attack the phantom widgets - at least I will try :-) cheers, Johannes
participants (3)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
place＠gobigwest.com