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?
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. -- Cheers Jorge.-
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.
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
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.
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
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...
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...
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
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 ()
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/
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.
Hi, At this point, there seems to be something wrong with the way the OS is handling its sockets and making them available to the application (after all, the freezes happen within system calls). Please try dillo and don't use any dpis, this will use remote TCP sockets only. Just plain web browsing. If this doesn't freeze, then there's a problem with local sockets. If plain web browsing works, you can try letting a chance to the OS's defaults by commenting setsockopt in: IO/dpi.c // line 442 in repo dpid/dpid.c // line 525 in repo recompile stop dpid // `dpidc stop` reinstall // make install retry If it doesn't work, check with dillo-2.0. If it works (dpis included) we'll assert it's a problem with the OS and the handling of local TCP sockets. HTH. On Sat, Jun 19, 2010 at 01:54:33AM +0000, corvid wrote:
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...
-- Cheers Jorge.-
On Sun, 20 Jun 2010 10:02:50 -0400, Jorge Arellano Cid wrote:
Hi,
At this point, there seems to be something wrong with the way the OS is handling its sockets and making them available to the application (after all, the freezes happen within system calls).
Please try dillo and don't use any dpis, this will use remote TCP sockets only. Just plain web browsing. If this doesn't freeze, then there's a problem with local sockets.
Yea -- the freezes only occur with the dpis. (Either cookie-websites or local file browsing, or bookmarks, etc)
If plain web browsing works, you can try letting a chance to the OS's defaults by commenting setsockopt in:
IO/dpi.c // line 442 in repo dpid/dpid.c // line 525 in repo
recompile stop dpid // `dpidc stop` reinstall // make install retry
That actually helped! I hesitated to post, because I did get one freeze a few days ago when trying to download a file (file.c), I didn't strace it to find which call exactly caused it, but otherwise that did seem to fix things! (Any ideas why the TCP_NODELAY flag is causing problems? :P)
On Wed, 23 Jun 2010 09:19:10 -0400, Dennis Nezic wrote:
On Sun, 20 Jun 2010 10:02:50 -0400, Jorge Arellano Cid wrote:
Hi,
At this point, there seems to be something wrong with the way the OS is handling its sockets and making them available to the application (after all, the freezes happen within system calls).
Please try dillo and don't use any dpis, this will use remote TCP sockets only. Just plain web browsing. If this doesn't freeze, then there's a problem with local sockets.
Yea -- the freezes only occur with the dpis. (Either cookie-websites or local file browsing, or bookmarks, etc)
If plain web browsing works, you can try letting a chance to the OS's defaults by commenting setsockopt in:
IO/dpi.c // line 442 in repo dpid/dpid.c // line 525 in repo
recompile stop dpid // `dpidc stop` reinstall // make install retry
That actually helped! I hesitated to post, because I did get one freeze a few days ago when trying to download a file (file.c), I didn't strace it to find which call exactly caused it, but otherwise that did seem to fix things! (Any ideas why the TCP_NODELAY flag is causing problems? :P)
I should have hesitated. The freezes are back, about as frequently as before. But I guess there's nothing dillo can do about it :\. socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5 connect(5, {sa_family=AF_INET, sin_port=htons(5020), sin_addr=inet_addr ("127.0.0.1")}, 16 **~minute freeze**) = -1 ETIMEDOUT (Connection timed out)
On Sun, 27 Jun 2010 08:22:38 -0400, Dennis Nezic wrote:
On Wed, 23 Jun 2010 09:19:10 -0400, Dennis Nezic wrote:
On Sun, 20 Jun 2010 10:02:50 -0400, Jorge Arellano Cid wrote:
Hi,
At this point, there seems to be something wrong with the way the OS is handling its sockets and making them available to the application (after all, the freezes happen within system calls).
Please try dillo and don't use any dpis, this will use remote TCP sockets only. Just plain web browsing. If this doesn't freeze, then there's a problem with local sockets.
Yea -- the freezes only occur with the dpis. (Either cookie-websites or local file browsing, or bookmarks, etc)
If plain web browsing works, you can try letting a chance to the OS's defaults by commenting setsockopt in:
IO/dpi.c // line 442 in repo dpid/dpid.c // line 525 in repo
recompile stop dpid // `dpidc stop` reinstall // make install retry
That actually helped! I hesitated to post, because I did get one freeze a few days ago when trying to download a file (file.c), I didn't strace it to find which call exactly caused it, but otherwise that did seem to fix things! (Any ideas why the TCP_NODELAY flag is causing problems? :P)
I should have hesitated. The freezes are back, about as frequently as before. But I guess there's nothing dillo can do about it :\.
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(5020), sin_addr=inet_addr ("127.0.0.1")}, 16 **~minute freeze**) = -1 ETIMEDOUT (Connection timed out)
Blargh. I'm not sure how to debug further. Netstat shows that dpid's sockets are in a LISTEN state during the freezes. Dillo's connection to dpid, according to netstat, is SYN_SENT. Telnet'ing to the dpid ports doesn't work during the freezes -- which sounds like a problem with dpid? But these freezes aren't "hard" -- sometimes they work -- once in a while it is able to unfreeze itself, at least for a bit, and I am able to telnet into dpid. Maybe dpid (or linux) is throttling socket connections or something? :|
On Sun, Jul 04, 2010 at 10:46:50AM -0400, Dennis Nezic wrote:
On Sun, 27 Jun 2010 08:22:38 -0400, Dennis Nezic wrote:
On Wed, 23 Jun 2010 09:19:10 -0400, Dennis Nezic wrote:
On Sun, 20 Jun 2010 10:02:50 -0400, Jorge Arellano Cid wrote:
Hi,
At this point, there seems to be something wrong with the way the OS is handling its sockets and making them available to the application (after all, the freezes happen within system calls).
Please try dillo and don't use any dpis, this will use remote TCP sockets only. Just plain web browsing. If this doesn't freeze, then there's a problem with local sockets.
Yea -- the freezes only occur with the dpis. (Either cookie-websites or local file browsing, or bookmarks, etc)
If plain web browsing works, you can try letting a chance to the OS's defaults by commenting setsockopt in:
IO/dpi.c // line 442 in repo dpid/dpid.c // line 525 in repo
recompile stop dpid // `dpidc stop` reinstall // make install retry
That actually helped! I hesitated to post, because I did get one freeze a few days ago when trying to download a file (file.c), I didn't strace it to find which call exactly caused it, but otherwise that did seem to fix things! (Any ideas why the TCP_NODELAY flag is causing problems? :P)
I should have hesitated. The freezes are back, about as frequently as before. But I guess there's nothing dillo can do about it :\.
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(5020), sin_addr=inet_addr ("127.0.0.1")}, 16 **~minute freeze**) = -1 ETIMEDOUT (Connection timed out)
Blargh. I'm not sure how to debug further. Netstat shows that dpid's sockets are in a LISTEN state during the freezes. Dillo's connection to dpid, according to netstat, is SYN_SENT. Telnet'ing to the dpid ports doesn't work during the freezes -- which sounds like a problem with dpid? But these freezes aren't "hard" -- sometimes they work -- once in a while it is able to unfreeze itself, at least for a bit, and I am able to telnet into dpid. Maybe dpid (or linux) is throttling socket connections or something? :|
I believe the problem is in the way your particular kernel interacts with dillo. No other GNU/Linux (nor BSD) that we know of has this problem. As I'm no kernel expert, it's hard for me to suggest a way to further debug the problem. You may try compiling a vanilla kernel from kernel.org or another kernel version from gentoo, or if you really want to find out where the freezes come from, asking a knowledgeable guy from the TCP sockets area in Linux. BTW, I'd bet it doesn't happen with Unix domain sockets, that's why I suggested trying dillo-2.0. Have you tried that? -- Cheers Jorge.-
On Mon, 5 Jul 2010 08:47:29 -0400, Jorge Arellano Cid wrote:
On Sun, Jul 04, 2010 at 10:46:50AM -0400, Dennis Nezic wrote:
On Sun, 27 Jun 2010 08:22:38 -0400, Dennis Nezic wrote:
On Wed, 23 Jun 2010 09:19:10 -0400, Dennis Nezic wrote:
On Sun, 20 Jun 2010 10:02:50 -0400, Jorge Arellano Cid wrote:
Hi,
At this point, there seems to be something wrong with the way the OS is handling its sockets and making them available to the application (after all, the freezes happen within system calls).
Please try dillo and don't use any dpis, this will use remote TCP sockets only. Just plain web browsing. If this doesn't freeze, then there's a problem with local sockets.
Yea -- the freezes only occur with the dpis. (Either cookie-websites or local file browsing, or bookmarks, etc)
If plain web browsing works, you can try letting a chance to the OS's defaults by commenting setsockopt in:
IO/dpi.c // line 442 in repo dpid/dpid.c // line 525 in repo
recompile stop dpid // `dpidc stop` reinstall // make install retry
That actually helped! I hesitated to post, because I did get one freeze a few days ago when trying to download a file (file.c), I didn't strace it to find which call exactly caused it, but otherwise that did seem to fix things! (Any ideas why the TCP_NODELAY flag is causing problems? :P)
I should have hesitated. The freezes are back, about as frequently as before. But I guess there's nothing dillo can do about it :\.
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(5020), sin_addr=inet_addr ("127.0.0.1")}, 16 **~minute freeze**) = -1 ETIMEDOUT (Connection timed out)
Blargh. I'm not sure how to debug further. Netstat shows that dpid's sockets are in a LISTEN state during the freezes. Dillo's connection to dpid, according to netstat, is SYN_SENT. Telnet'ing to the dpid ports doesn't work during the freezes -- which sounds like a problem with dpid? But these freezes aren't "hard" -- sometimes they work -- once in a while it is able to unfreeze itself, at least for a bit, and I am able to telnet into dpid. Maybe dpid (or linux) is throttling socket connections or something? :|
I believe the problem is in the way your particular kernel interacts with dillo. No other GNU/Linux (nor BSD) that we know of has this problem. As I'm no kernel expert, it's hard for me to suggest a way to further debug the problem.
You may try compiling a vanilla kernel from kernel.org or another kernel version from gentoo, or if you really want to find out where the freezes come from, asking a knowledgeable guy from the TCP sockets area in Linux.
BTW, I'd bet it doesn't happen with Unix domain sockets, that's why I suggested trying dillo-2.0. Have you tried that?
You're right. About everything :). The freezes don't happen with 2.0. I miss the good blazing-fast old days, sometimes. They also don't seem to happen after I downgraded my kernel from 2.6.35-rc3 to 2.6.34. (Although now I have other networking problems -- nfs/scp/etc stalls :S). Thanks for the help and tips!
Dennis wrote:
You're right. About everything :). The freezes don't happen with 2.0. I miss the good blazing-fast old days, sometimes. They also don't seem to happen after I downgraded my kernel from 2.6.35-rc3 to 2.6.34. (Although now I have other networking problems -- nfs/scp/etc stalls :S).
I wonder whether there's any connection with http://kerneltrap.org/mailarchive/linux-kernel/2010/6/14/4582843/thread
On Tue, Jul 06, 2010 at 03:19:57AM +0000, corvid wrote:
Dennis wrote:
You're right. About everything :). The freezes don't happen with 2.0. I miss the good blazing-fast old days, sometimes. They also don't seem to happen after I downgraded my kernel from 2.6.35-rc3 to 2.6.34. (Although now I have other networking problems -- nfs/scp/etc stalls :S).
I wonder whether there's any connection with http://kerneltrap.org/mailarchive/linux-kernel/2010/6/14/4582843/thread
Exact match! (I wonder how you found it) There's even a one-liner patch for the problem in the thread: http://lkml.org/lkml/2010/6/13/155 Have you tried it Dennis? -- Cheers Jorge.-
On Tue, 6 Jul 2010 09:47:19 -0400, Jorge Arellano Cid wrote:
On Tue, Jul 06, 2010 at 03:19:57AM +0000, corvid wrote:
Dennis wrote:
You're right. About everything :). The freezes don't happen with 2.0. I miss the good blazing-fast old days, sometimes. They also don't seem to happen after I downgraded my kernel from 2.6.35-rc3 to 2.6.34. (Although now I have other networking problems -- nfs/scp/etc stalls :S).
I wonder whether there's any connection with http://kerneltrap.org/mailarchive/linux-kernel/2010/6/14/4582843/thread
Exact match! (I wonder how you found it)
There's even a one-liner patch for the problem in the thread: http://lkml.org/lkml/2010/6/13/155
Have you tried it Dennis?
It seems to have worked!! Joy!
On Mon, Jul 05, 2010 at 09:32:55PM -0400, Dennis Nezic wrote:
You're right. About everything :). The freezes don't happen with 2.0. I miss the good blazing-fast old days, sometimes. They also don't seem to happen after I downgraded my kernel from 2.6.35-rc3 to 2.6.34. (Although now I have other networking problems -- nfs/scp/etc stalls :S).
From what I saw from the patches, they almost rewrote the entire driver -- but
This doesn't surprise me one bit. If I can recall correctly, when kernel-2.6.30 was released, somebody submitted a few firmware patches in for a specific network adapter (whose driver is in the kernel). The patches were accepted into the 2.6.30 version breaking the driver at first, then later wake on LAN functions. the author did state he should have caught the bugs. The bugs have long since been fixed, but it does bring up an issue concerning kernel stability. However, I also realize if they try improving the quality of the kernel drivers, you might not see the patch integration until 2.7 or 2.8! Might also want to check out remote GDB to debug the kernel. -- Roger http://rogerx.freeshell.org/
On Mon, Jul 05, 2010 at 09:32:55PM -0400, Dennis Nezic wrote:
On Mon, 5 Jul 2010 08:47:29 -0400, Jorge Arellano Cid wrote:
On Sun, Jul 04, 2010 at 10:46:50AM -0400, Dennis Nezic wrote:
On Sun, 27 Jun 2010 08:22:38 -0400, Dennis Nezic wrote:
On Wed, 23 Jun 2010 09:19:10 -0400, Dennis Nezic wrote:
On Sun, 20 Jun 2010 10:02:50 -0400, Jorge Arellano Cid wrote:
Hi,
At this point, there seems to be something wrong with the way the OS is handling its sockets and making them available to the application (after all, the freezes happen within system calls).
Please try dillo and don't use any dpis, this will use remote TCP sockets only. Just plain web browsing. If this doesn't freeze, then there's a problem with local sockets.
Yea -- the freezes only occur with the dpis. (Either cookie-websites or local file browsing, or bookmarks, etc)
If plain web browsing works, you can try letting a chance to the OS's defaults by commenting setsockopt in:
IO/dpi.c // line 442 in repo dpid/dpid.c // line 525 in repo
recompile stop dpid // `dpidc stop` reinstall // make install retry
That actually helped! I hesitated to post, because I did get one freeze a few days ago when trying to download a file (file.c), I didn't strace it to find which call exactly caused it, but otherwise that did seem to fix things! (Any ideas why the TCP_NODELAY flag is causing problems? :P)
I should have hesitated. The freezes are back, about as frequently as before. But I guess there's nothing dillo can do about it :\.
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(5020), sin_addr=inet_addr ("127.0.0.1")}, 16 **~minute freeze**) = -1 ETIMEDOUT (Connection timed out)
Blargh. I'm not sure how to debug further. Netstat shows that dpid's sockets are in a LISTEN state during the freezes. Dillo's connection to dpid, according to netstat, is SYN_SENT. Telnet'ing to the dpid ports doesn't work during the freezes -- which sounds like a problem with dpid? But these freezes aren't "hard" -- sometimes they work -- once in a while it is able to unfreeze itself, at least for a bit, and I am able to telnet into dpid. Maybe dpid (or linux) is throttling socket connections or something? :|
I believe the problem is in the way your particular kernel interacts with dillo. No other GNU/Linux (nor BSD) that we know of has this problem. As I'm no kernel expert, it's hard for me to suggest a way to further debug the problem.
You may try compiling a vanilla kernel from kernel.org or another kernel version from gentoo, or if you really want to find out where the freezes come from, asking a knowledgeable guy from the TCP sockets area in Linux.
BTW, I'd bet it doesn't happen with Unix domain sockets, that's why I suggested trying dillo-2.0. Have you tried that?
You're right. About everything :).
Got a funny feeling here :)
The freezes don't happen with 2.0. I miss the good blazing-fast old days, sometimes.
Do you mean dillo-2.0 is much faster than current repo even with a good kernel (i.e. no loobpack bug)? Please explain.
They also don't seem to happen after I downgraded my kernel from 2.6.35-rc3 to 2.6.34. (Although now I have other networking problems -- nfs/scp/etc stalls :S).
Thanks for the help and tips!
You're welcome. -- Cheers Jorge.-
On Sun, 27 Jun 2010 08:22:38 -0400, Dennis Nezic wrote:
On Wed, 23 Jun 2010 09:19:10 -0400, Dennis Nezic wrote:
On Sun, 20 Jun 2010 10:02:50 -0400, Jorge Arellano Cid wrote:
Hi,
At this point, there seems to be something wrong with the way the OS is handling its sockets and making them available to the application (after all, the freezes happen within system calls).
Please try dillo and don't use any dpis, this will use remote TCP sockets only. Just plain web browsing. If this doesn't freeze, then there's a problem with local sockets.
Yea -- the freezes only occur with the dpis. (Either cookie-websites or local file browsing, or bookmarks, etc)
If plain web browsing works, you can try letting a chance to the OS's defaults by commenting setsockopt in:
IO/dpi.c // line 442 in repo dpid/dpid.c // line 525 in repo
recompile stop dpid // `dpidc stop` reinstall // make install retry
That actually helped! I hesitated to post, because I did get one freeze a few days ago when trying to download a file (file.c), I didn't strace it to find which call exactly caused it, but otherwise that did seem to fix things! (Any ideas why the TCP_NODELAY flag is causing problems? :P)
I should have hesitated. The freezes are back, about as frequently as before. But I guess there's nothing dillo can do about it :\.
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(5020), sin_addr=inet_addr ("127.0.0.1")}, 16 **~minute freeze**) = -1 ETIMEDOUT (Connection timed out)
I have also noticed that, after 11 tries, ... Dpi_blocking_start_dpid: try 11 Dpi_check_dpid_ids: Connection timed out dpid seems to respawn itself, with a new mksecret (updated dpid_comm_keys). Why is it respawning itself without stopping it's earlier instances?
participants (5)
-
corvid＠lavabit.com -
dennisn＠dennisn.dyndns.org -
jcid＠dillo.org -
onepoint＠starurchin.org -
rogerx＠sdf.org