- Dillo-dev - lists.mailman3.com

missing occasional messages on dillo-dev

by place＠gobigwest.com

I've been missing the occasional message lately. I do not have any spam filtering. Does whoever admins the list have any insight?

March 20, 2008

removeIdle: *** [unknown] This should not happen! *** Aborted

by place＠gobigwest.com

I think I mentioned this problem some time ago, but playing with ComplexButton makes it much worse (when meta charset causes a repush). The backtrace shows that it's unhappy because IdleFunc doesn't have an equals(). To make the problem go away, I changed the remove in FltkPlatform::removeIdle() to a removeRef, but, again, I don't know this code well enough to know what should be going on. #0 0x40344c81 in kill () from /lib/libc.so.6 #1 0x401b04a1 in pthread_kill () from /lib/libpthread.so.0 #2 0x401b087b in raise () from /lib/libpthread.so.0 #3 0x403448f8 in raise () from /lib/libc.so.6 #4 0x40345f00 in abort () from /lib/libc.so.6 #5 0x0809e054 in misc::assertNotReached () at misc.hh:67 #6 0x080ad6f1 in object::Object::equals (this=0x81ab118, other=0x81ab118) at object.cc:49 #7 0x080aa182 in container::untyped::List::remove0 (this=0x81c1b90, element=0x81ab118, compare=true, doNotDeleteAtAll=false) at container.cc:254 #8 0x080891c7 in container::untyped::List::remove (this=0x81c1b90, element=0x81ab118) at ../lout/container.hh:169 #9 0x080891eb in container::typed::List<dw::fltk::FltkPlatform::IdleFunc>::remo ve (this=0x81c1960, element=0x81ab118) at ../lout/container.hh:376 #10 0x08086968 in dw::fltk::FltkPlatform::removeIdle (this=0x81c1b68, idleId=1) at fltkplatform.cc:319 #11 0x0809feaa in ~Layout (this=0x81c1bf8) at layout.cc:117

March 20, 2008

patch: Re: [Dillo-dev] multiple-scan images consume a lot of CPU

by place＠gobigwest.com

Jorge wrote: > I'd prefer to be sure that cached images always render in one pass, > but this workaround is simple and good enough to commit, until someone > comes with a better idea. Well, there was some discussion not too long ago on the list about a capi interface to get the status of cache entries... :)

March 20, 2008

ComplexButton crashing

by place＠gobigwest.com

For you dw people... I am working on getting ComplexButton to work (image inputs), and it would segfault when I'd close the bw. In FltkComplexButtonResource::createNewWidget, the button's child is a view. When the button is destroyed, since the button is a Group, its children get destroyed. Later on, the layout is being destroyed, and it deletes TopLevel. The toplevel widget destructor calls layout->removeWidget(), which tries to iterate through the views. To make the problem go away, I added: fltkcomplexbutton.hh: ~ComplexButton() {remove_all();} but I don't know any of this code well enough to know what _should_ be going on.

March 20, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by darkspirit5000＠gmail.com

I do not have problem with that page, but ... I have suffer the same problem(i think) in dillo-gtk few times, but can not reproduce it. I am interested in resolve this bug, but do not have time. Now that the problem happen always maybe we can catch the bug. Try to gdb the dpid or cookies.dpi I think the problem is about the cookies.dpi: cookies.dpi can not start, it die before send an answer to dillo and the dpid restart it one and other time with same result. Dillo wait blocked forever the answer(because a_Dpi_send_blocking_cmd()). To recover the blocked dillo you can stop dpid and at the same time kill the various cookies.dpi running. Te reason to have or not to have this problem, can be to have enabled cookies for that site Diego. 2008/3/20, Jeremy Henty <onepoint(a)starurchin.org>: > > On Wed, Mar 19, 2008 at 07:55:35PM +0000, place wrote: > > Jorge wrote: > > > I just noticed that calling current CVS with: > > > > > > http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 > > > > > > completely blocks the browser. > > > > > > It doesn't happen with older dillo2 versions. > > > > > > Please give it a look. > > > > No problems for me, either with or without cookies. > > > It consistently hangs the latest CVS for me. I have attached the gdb > backtrace. > > For a while not so long ago one of my ISP's pages also hung Dillo in > a_Dpi_send_blocking_cmd() . The problem went away before I got round > to investigating it properly. I don't know if it fixed itself due to > a change in the page, a change in Dillo or some other factor. I > mention it now to point out that this problem *may* have been around > for a little while in some form or other (though I can't be certain). > > Regards, > > > Jeremy Henty > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > >

March 20, 2008

patch: Re: [Dillo-dev] multiple-scan images consume a lot of CPU

by jcid＠dillo.org

On Sun, Mar 16, 2008 at 04:41:08PM +0000, place wrote: > > Your patch below works great for me. > > :) > > Here's a proper patch with proper comments. > > PS If anybody happens to have deep knowledge of various sorts of > networking, maybe they'll know an optimal value for a BufSize test. > All I know is that modem mtu is 15xx. > Committed. I'd prefer to be sure that cached images always render in one pass, but this workaround is simple and good enough to commit, until someone comes with a better idea. -- Cheers Jorge.-

March 20, 2008

[patch] don't allocate tagnames on stack

by jcid＠dillo.org

On Sun, Mar 16, 2008 at 05:05:57PM +0100, Johannes Hofmann wrote: > On Sun, Mar 16, 2008 at 10:47:07AM -0400, Jorge Arellano Cid wrote: > > On Thu, Mar 13, 2008 at 09:01:37PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > here is another patch that avoids some malloc/free calls. > > > > > > > I decided to completely remove tag_name, and to use Tags[tag_idx]. > > Please check the patch in CVS. > > Cool. That's even better. > > > > > BTW, with regard to these optimizations (which I was very fond of), > > profiling showed me that the zen of speed is to attack the main bottleneck... > > Can you build a statically linked binary with > profiling enabled? Here it does not work for some reason, so the > timings in the gprof output are bogus. Only the counters work > reliably. I've done it lots of times in the past, with: ./configure --enable-gprof or CFLAGS="-g -O0" CXXFLAGS="-g -O0" ./configure --enable-gprof but now that I test, it doesn't work anymore! !? -- Cheers Jorge.-

March 20, 2008

https plugin status

by jcid＠dillo.org

On Sat, Mar 15, 2008 at 08:21:23PM +0000, Jeremy Henty wrote: > On Sat, Mar 15, 2008 at 03:31:52PM -0400, Jorge Arellano Cid wrote: > > > > [Jeremey wrote] > > > Or maybe Capi_url_uses_dpi() should be checking for "https" and > > > *not* adding the "proto." prefix? > > > > "proto.https" is the right patch. > > OK, what about my patch to redirect MSG debugging messages from stdout > to stderr? Is that correct? Dpi programs are reading and writing from the stdin descriptor, and all of them send debug messages to stdout. I think this is correct, or at least standard by now. -- Cheers Jorge.-

March 20, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by jcid＠dillo.org

On Wed, Mar 19, 2008 at 07:55:35PM +0000, place wrote: > Jorge wrote: > > I just noticed that calling current CVS with: > > > > http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 > > > > completely blocks the browser. > > > > It doesn't happen with older dillo2 versions. > > > > Please give it a look. > > No problems for me, either with or without cookies. Oh! I'm on dialup now and have: www.fltk.org ACCEPT_SESSION in cookiesrc. It blocks for me on every try... -- Cheers Jorge.-

March 20, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by onepoint＠starurchin.org

On Wed, Mar 19, 2008 at 07:55:35PM +0000, place wrote: > Jorge wrote: > > I just noticed that calling current CVS with: > > > > http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 > > > > completely blocks the browser. > > > > It doesn't happen with older dillo2 versions. > > > > Please give it a look. > > No problems for me, either with or without cookies. It consistently hangs the latest CVS for me. I have attached the gdb backtrace. For a while not so long ago one of my ISP's pages also hung Dillo in a_Dpi_send_blocking_cmd() . The problem went away before I got round to investigating it properly. I don't know if it fixed itself due to a change in the page, a change in Dillo or some other factor. I mention it now to point out that this problem *may* have been around for a little while in some form or other (though I can't be certain). Regards, Jeremy Henty

March 20, 2008