- Dillo-dev - lists.mailman3.com

Re: dillo mysteriously freezes

by corvid＠lavabit.com

Dennis wrote: > Hrrm, although I don't have blackhole (I run "normal" Gentoo here) after > I strace'ed dillo during the freezes, it might be related. > > Here is the part of the strace immediately before and after the > freeze(s): > > 2:24: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6 > 2:24: setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 > **freeze** > 2:45: connect(6, {sa_family=AF_INET, sin_port=htons(5020), > sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed > out) > 2:45: write(1, "Dpi_check_dpid_ids: Connection > t"...,41Dpi_check_dpid_ids: Connection timed out > > (and a bit later, another freeze:) > > 2:46: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 > 2:46: setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0 > **freeze** > 3:07: connect(7, {sa_family=AF_INET, sin_port=htons(5029), > sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed > out) > 3:07: write(1, "Dpi_get_server_port: Connection > "...,42Dpi_get_server_port: Connection timed out 3:07: ) = 42 > > Here is a more complete strace: > http://dennisn.dyndns.org/guest/pubstuff/dillo-strace-freeze > > Any idea what else can be causing these timeouts? :\ I already used up my relevant TCP knowledge on my previous guess... > Oh, by the way, while I was testing the bookmarks.dpi (by loading > "dpi:/bm/") and refreshing repeatedly, not only did I get the freeze, > but I also managed to get a Segmentation Fault :s... > > Nav_open_url: new url='dpi:/bm/' > [fopen]: No such file or directory > a_Nav_expect_done: reload! > Nav_open_url: new url='dpi:/bm/' > [dpi::connect] errno:110 Connection timed out > ** ERROR **: dpi.c: can't start dpi daemon > [New Thread 0x7f6945a41720 (LWP 31505)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7f6945a41720 (LWP 31505)] > ---Type <return> to continue, or q <return> to quit--- > 0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 > (gdb) bt > #0 0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 > #1 0x000000000043de72 in dStrdup () > #2 0x0000000000414dd7 in Url_object_new () > #3 0x0000000000415247 in a_Url_dup () > #4 0x0000000000410b68 in a_Bw_add_url () > #5 0x00000000004175d3 in Nav_open_url () > #6 0x00007f6944e564cf in fltk::wait () from /usr/lib64/fltk/libfltk2.so > #7 0x00007f6944e56595 in fltk::run () from /usr/lib64/fltk/libfltk2.so > #8 0x000000000040af23 in main () It doesn't break for me, unfortunately. I imagine that must be from Nav_reload_callback(). Maybe Jorge will know could happen to the a_History_get_url(NAV_TOP_UIDX(bw)) by the time that fltk gets around to calling it.

June 19, 2010

Re: dillo mysteriously freezes

by rogerx＠sdf.org

On Fri, Jun 18, 2010 at 04:56:05PM -0400, Dennis Nezic wrote: >Hrrm, although I don't have blackhole (I run "normal" Gentoo here) after >I strace'ed dillo during the freezes, it might be related. I use Gentoo here too, and use the following USE Flags: =x11-libs/fltk-2.0_pre697 jpeg png xft zlib =www-client/dillo-2.2 gif ipv6 jpeg png ssl >Program received signal SIGSEGV, Segmentation fault. >[Switching to Thread 0x7f6945a41720 (LWP 31505)] >---Type <return> to continue, or q <return> to quit--- >0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 >(gdb) bt >#0 0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 >#1 0x000000000043de72 in dStrdup () >#2 0x0000000000414dd7 in Url_object_new () >#3 0x0000000000415247 in a_Url_dup () >#4 0x0000000000410b68 in a_Bw_add_url () >#5 0x00000000004175d3 in Nav_open_url () >#6 0x00007f6944e564cf in fltk::wait () from /usr/lib64/fltk/libfltk2.so >#7 0x00007f6944e56595 in fltk::run () from /usr/lib64/fltk/libfltk2.so >#8 0x000000000040af23 in main () I don't see this problem here. CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer" =sys-devel/gcc-4.3.4 fortran mudflap nls nptl openmp =sys-devel/gcc-4.4.3-r2 fortran mudflap nls nptl openmp =sys-libs/glibc-2.10.1-r1 nls If there's info I can provide for comparison, let me know. I only saw the "variable font segfault" and was solved by building fltk with xft USE Flag. Following fonts are installed here: media-fonts/arkpandora media-fonts/dejavu media-fonts/encodings media-fonts/font-alias media-fonts/font-bitstream-100dpi media-fonts/font-bitstream-type1 media-fonts/terminus-font media-fonts/ttf-bitstream-vera media-fonts/urw-fonts virtual/ttf-fonts x11-apps/mkfontscale x11-proto/fontsproto Using pretty much a bare install here using minimal number of packages to get X working with DWM. -- Roger http://rogerx.freeshell.org/

June 19, 2010

Re: dillo mysteriously freezes

by dennisn＠dennisn.dyndns.org

On Fri, 18 Jun 2010 00:25:32 +0000, corvid wrote: > Dennis wrote: > > On Thu, 17 Jun 2010 21:37:23 +0000, corvid wrote: > > > Jeremy wrote: > > > > On Thu, Jun 17, 2010 at 02:42:19PM -0400, Dennis Nezic wrote: > > > > > > > > > Interesting. It appears that I only get these freezes when > > > > > I have cookies enabled. If I set my cookiesrc file back to > > > > > "DEFAULT DENY" (with no "hostname ACCEPT" afterwards), I no > > > > > longer get the freezes. > > > > > > > > That's useful confirmation that it's a cookies problem. > > > > > > Does the DPI stuff work otherwise? Bookmarks, https:, file:... > > > > Bah. It looks like all the dpi stuff is commonly affected. I tried > > browsing locally with file:// and the same thing occurred. It also > > did unfreeze after about a minute. > > I wonder whether you're using blackhole by any chance. > > The issue was brought up in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-January/007247.html > and at least seemed to be resolved in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-February/007283.html Hrrm, although I don't have blackhole (I run "normal" Gentoo here) after I strace'ed dillo during the freezes, it might be related. Here is the part of the strace immediately before and after the freeze(s): 2:24: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6 2:24: setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0 **freeze** 2:45: connect(6, {sa_family=AF_INET, sin_port=htons(5020), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed out) 2:45: write(1, "Dpi_check_dpid_ids: Connection t"...,41Dpi_check_dpid_ids: Connection timed out (and a bit later, another freeze:) 2:46: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 7 2:46: setsockopt(7, SOL_TCP, TCP_NODELAY, [1], 4) = 0 **freeze** 3:07: connect(7, {sa_family=AF_INET, sin_port=htons(5029), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed out) 3:07: write(1, "Dpi_get_server_port: Connection "...,42Dpi_get_server_port: Connection timed out 3:07: ) = 42 Here is a more complete strace: http://dennisn.dyndns.org/guest/pubstuff/dillo-strace-freeze Any idea what else can be causing these timeouts? :\ Oh, by the way, while I was testing the bookmarks.dpi (by loading "dpi:/bm/") and refreshing repeatedly, not only did I get the freeze, but I also managed to get a Segmentation Fault :s... Nav_open_url: new url='dpi:/bm/' [fopen]: No such file or directory a_Nav_expect_done: reload! Nav_open_url: new url='dpi:/bm/' [dpi::connect] errno:110 Connection timed out ** ERROR **: dpi.c: can't start dpi daemon [New Thread 0x7f6945a41720 (LWP 31505)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f6945a41720 (LWP 31505)] ---Type <return> to continue, or q <return> to quit--- 0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 (gdb) bt #0 0x00007f69439a2cc2 in strlen () from /lib/libc.so.6 #1 0x000000000043de72 in dStrdup () #2 0x0000000000414dd7 in Url_object_new () #3 0x0000000000415247 in a_Url_dup () #4 0x0000000000410b68 in a_Bw_add_url () #5 0x00000000004175d3 in Nav_open_url () #6 0x00007f6944e564cf in fltk::wait () from /usr/lib64/fltk/libfltk2.so #7 0x00007f6944e56595 in fltk::run () from /usr/lib64/fltk/libfltk2.so #8 0x000000000040af23 in main ()

June 18, 2010

Re: dillo mysteriously freezes

by corvid＠lavabit.com

Dennis wrote: > On Thu, 17 Jun 2010 21:37:23 +0000, corvid wrote: > > Jeremy wrote: > > > On Thu, Jun 17, 2010 at 02:42:19PM -0400, Dennis Nezic wrote: > > > > > > > Interesting. It appears that I only get these freezes when I > > > > have cookies enabled. If I set my cookiesrc file back to > > > > "DEFAULT DENY" (with no "hostname ACCEPT" afterwards), I no > > > > longer get the freezes. > > > > > > That's useful confirmation that it's a cookies problem. > > > > Does the DPI stuff work otherwise? Bookmarks, https:, file:... > > Bah. It looks like all the dpi stuff is commonly affected. I tried > browsing locally with file:// and the same thing occurred. It also did > unfreeze after about a minute. I wonder whether you're using blackhole by any chance. The issue was brought up in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-January/007247.html and at least seemed to be resolved in http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-February/007283.html

June 18, 2010

Re: dillo mysteriously freezes

by dennisn＠dennisn.dyndns.org

On Thu, 17 Jun 2010 21:37:23 +0000, corvid wrote: > Jeremy wrote: > > On Thu, Jun 17, 2010 at 02:42:19PM -0400, Dennis Nezic wrote: > > > > > Interesting. It appears that I only get these freezes when I > > > have cookies enabled. If I set my cookiesrc file back to > > > "DEFAULT DENY" (with no "hostname ACCEPT" afterwards), I no > > > longer get the freezes. > > > > That's useful confirmation that it's a cookies problem. > > Does the DPI stuff work otherwise? Bookmarks, https:, file:... Bah. It looks like all the dpi stuff is commonly affected. I tried browsing locally with file:// and the same thing occurred. It also did unfreeze after about a minute. > > > > > ps -ef | grep dpi doesn't show anything interesting: > > > 1533 1 0 14:31 ? 00:00:00 dpid > > > 1534 1533 0 14:31 ? > > > 00:00:00 /usr/lib64/dillo/dpi/cookies/cookies.dpi > > > > It shows that neither the DPI daemon or the cookies DPI have > > crashed, which is something. I wonder what the cookies DPI is > > doing? Does anyone know how to attach gdb to the cookies DPI > > and see where it's at? > > gdb /usr/lib64/dillo/dpi/cookies/cookies.dpi 1534 > or something along those lines...

June 18, 2010

Re: dillo mysteriously freezes

by corvid＠lavabit.com

Jeremy wrote: > On Thu, Jun 17, 2010 at 02:42:19PM -0400, Dennis Nezic wrote: > > > Interesting. It appears that I only get these freezes when I have > > cookies enabled. If I set my cookiesrc file back to "DEFAULT DENY" > > (with no "hostname ACCEPT" afterwards), I no longer get the freezes. > > That's useful confirmation that it's a cookies problem. Does the DPI stuff work otherwise? Bookmarks, https:, file:... > > ps -ef | grep dpi doesn't show anything interesting: > > 1533 1 0 14:31 ? 00:00:00 dpid > > 1534 1533 0 14:31 ? 00:00:00 /usr/lib64/dillo/dpi/cookies/cookies.dpi > > It shows that neither the DPI daemon or the cookies DPI have crashed, > which is something. I wonder what the cookies DPI is doing? Does > anyone know how to attach gdb to the cookies DPI and see where it's > at? gdb /usr/lib64/dillo/dpi/cookies/cookies.dpi 1534 or something along those lines...

June 17, 2010

Re: dillo mysteriously freezes

by onepoint＠starurchin.org

On Thu, Jun 17, 2010 at 02:42:19PM -0400, Dennis Nezic wrote: > Interesting. It appears that I only get these freezes when I have > cookies enabled. If I set my cookiesrc file back to "DEFAULT DENY" > (with no "hostname ACCEPT" afterwards), I no longer get the freezes. That's useful confirmation that it's a cookies problem. > ps -ef | grep dpi doesn't show anything interesting: > 1533 1 0 14:31 ? 00:00:00 dpid > 1534 1533 0 14:31 ? 00:00:00 /usr/lib64/dillo/dpi/cookies/cookies.dpi It shows that neither the DPI daemon or the cookies DPI have crashed, which is something. I wonder what the cookies DPI is doing? Does anyone know how to attach gdb to the cookies DPI and see where it's at? Regards, Jeremy Henty

June 17, 2010

Re: dillo mysteriously freezes

by dennisn＠dennisn.dyndns.org

On Thu, 17 Jun 2010 19:03:32 +0100, Jeremy Henty wrote: > On Thu, Jun 17, 2010 at 01:36:47PM -0400, Dennis Nezic wrote: > > > (gdb) bt > > #0 0x00007f3cca17089d in connect () from /lib/libpthread.so.0 > > #1 0x000000000044227e in Dpi_connect_socket () > > #2 0x0000000000442f6f in a_Dpi_send_blocking_cmd () > > #3 0x0000000000411115 in a_Cookies_get_query () > > #4 0x000000000044098d in a_Http_make_query_str () > > #5 0x0000000000441481 in Http_connect_queued_sockets () > > #6 0x00000000004375da in Dns_timeout_client () > > #7 0x00007f3ccac8c4cf in fltk::wait () > > #from /usr/lib64/fltk/libfltk2.so 8 0x00007f3ccac8c595 in > > #fltk::run () from /usr/lib64/fltk/libfltk2.so 9 > > #0x000000000040af23 in main () > > It looks as though Dillo is waiting for an answer from the cookies DPI > and not getting one. What is the output of "ps -ef | grep dpi"? It > would also be useful if you could save the output of Dillo to a log > file and send it (it's unlikely to be a large file if Dillo hangs > after a few seconds). Interesting. It appears that I only get these freezes when I have cookies enabled. If I set my cookiesrc file back to "DEFAULT DENY" (with no "hostname ACCEPT" afterwards), I no longer get the freezes. ps -ef | grep dpi doesn't show anything interesting: 1533 1 0 14:31 ? 00:00:00 dpid 1534 1533 0 14:31 ? 00:00:00 /usr/lib64/dillo/dpi/cookies/cookies.dpi Sometimes, however, my cpu stalls at 100%, I think caused by dpid, but top only shows 17% from it -- (the rest I assume is some lower level system hook?) -- but this doesn't always happen. Also, I did see dillo unfreeze once, after a few seconds -- but that is rare.

June 17, 2010

Re: dillo mysteriously freezes

by onepoint＠starurchin.org

On Thu, Jun 17, 2010 at 01:36:47PM -0400, Dennis Nezic wrote: > (gdb) bt > #0 0x00007f3cca17089d in connect () from /lib/libpthread.so.0 > #1 0x000000000044227e in Dpi_connect_socket () > #2 0x0000000000442f6f in a_Dpi_send_blocking_cmd () > #3 0x0000000000411115 in a_Cookies_get_query () > #4 0x000000000044098d in a_Http_make_query_str () > #5 0x0000000000441481 in Http_connect_queued_sockets () > #6 0x00000000004375da in Dns_timeout_client () > #7 0x00007f3ccac8c4cf in fltk::wait () from /usr/lib64/fltk/libfltk2.so > #8 0x00007f3ccac8c595 in fltk::run () from /usr/lib64/fltk/libfltk2.so > #9 0x000000000040af23 in main () It looks as though Dillo is waiting for an answer from the cookies DPI and not getting one. What is the output of "ps -ef | grep dpi"? It would also be useful if you could save the output of Dillo to a log file and send it (it's unlikely to be a large file if Dillo hangs after a few seconds). Regards, Jeremy Henty

June 17, 2010

Re: dillo mysteriously freezes

by dennisn＠dennisn.dyndns.org

On Thu, 17 Jun 2010 11:14:43 -0400, Jorge Arellano Cid wrote: > On Thu, Jun 17, 2010 at 09:44:03AM -0400, Dennis Nezic wrote: > > I seem to be experiencing a very nasty bug that breaks my Dillo. A > > few seconds after starting dillo, it "freezes" -- standard-output > > stops, the graphics freeze and never get redrawn (resulting in those > > psychodelic effects of moving windows over a non-redrawing window). > > My dillo window then doesn't respond to my window manager's "close" > > events, and I have to manually kill it. > > > > I can't give you the exact steps to reproduce it -- sometimes it's > > like this immediately after starting ... sometimes it magically > > starts to happen a few seconds afterwards -- possibly after I click > > on a link. > > > > dillo-2.2 > > fltk-2_pre7513 (I also tried with earlier versions (6970)) > > > > Ideas? > > gdb dillo > <dillo freezes somewhere here> > ctrl-c > bt > > And send us the gdb backtrace. (gdb) bt #0 0x00007f3cca17089d in connect () from /lib/libpthread.so.0 #1 0x000000000044227e in Dpi_connect_socket () #2 0x0000000000442f6f in a_Dpi_send_blocking_cmd () #3 0x0000000000411115 in a_Cookies_get_query () #4 0x000000000044098d in a_Http_make_query_str () #5 0x0000000000441481 in Http_connect_queued_sockets () #6 0x00000000004375da in Dns_timeout_client () #7 0x00007f3ccac8c4cf in fltk::wait () from /usr/lib64/fltk/libfltk2.so #8 0x00007f3ccac8c595 in fltk::run () from /usr/lib64/fltk/libfltk2.so #9 0x000000000040af23 in main () I don't know if this helps -- but that's the bt for dillo after I ctrl-c, after the graphics/ui becomes unresponsive.

June 17, 2010