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.