Connection problems on Mac OS X 10.6.7
Hi guys, First post here, thanks for all your hard work on Dillo! I'm trying to compile and run dillo on Mac OS 10.6.7 (and report the bugs I find :D ). I followed instructions that Jorge sent me earlier, and it compiled without an error but a few warnings: $ make|grep : http.c: In function ?Http_connect_queued_sockets?: http.c:177: warning: cast from pointer to integer of different size dialog.cc: In function ?int a_Dialog_choice5(const char*, const char*, const char*, const char*, const char*, const char*)?: dialog.cc:177: warning: suggest a space before ?;? or explicit braces around empty body in ?for? statement make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all-am'. The good news is that Dillo runs. It also seems to eventually connect to websites, which is good news too. But at least for me loading a page is a hit or miss experiment. Sometimes it waits for a long time (maybe 2-3 minutes) and couldn't connect, as if there was a DNS problem, other times it loads the same page easily in a few seconds. Here's the output from the terminal, after trying to connect to yahoo.com site unsuccessfully (waiting for a long time): $ src/dillo paths: creating directory /Users/farivar2/.dillo. paths: Cannot open file '/Users/farivar2/.dillo/dillorc' paths: Using /usr/local/etc/dillo/dillorc paths: Cannot open file '/Users/farivar2/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Cookies: Created file: /Users/farivar2/.dillo/cookiesrc Disabling cookies. Nav_open_url: new url='about:splash' Nav_open_url: new url='http://www.yahoo.com' Dns_server [0]: www.yahoo.com is 209.191.122.70 69.147.125.65 67.195.160.76 Connecting to 209.191.122.70 and it almost hangs here. During this time the CPU utilization hovers around 134% (on a dual core machine), with 3 threads and 48MB of memory usage. Is this behavior expected? Perhaps it's related to the warnings above? My guess is that it's either a DNS problem or an HTTP connection problem, resulting into a time-out case. P.S. Sometimes it seems if I open another tab and enter another address it will help the first tab to load, but I can't get it to consistently act like that. Other times, it seems a tab can get stuck waiting for the host and can never load the page. It also seems adding http:// to the beggining of addresses help some times, but not consistently. P.S.2 I checked my network connection with my other browser (chrome) and it has no problem connecting the mentioned websites. P.S.3 Are there reference rendering snapshots available? The Yahoo's web site and even Google's both render in a strange way (similar to the way links2 renders them). In fact the only website that I could get to render correctly is dillo.org (when it opens, other times it just decides not to open even after 5 minutes of waiting). P.S.4 Jorge's instructions to compile dillo-1.3 for Mac OS X are as follows: 1.- <install fltk-1.3-rc5 from fltk.org> 2.- <install auto* tools, X devel, C/C++, jpeg, png, etc> 3.- <install mercurial> 4.- $ hg clone http://hg.dillo.org/dillo_port1.3 5.- $ cd dillo_port1.3 6.- $ ./autogen.sh 7.- $ CFLAGS="-g -O0" CXXFLAGS="-g -O0" ./configure --enable-ssl 8.- $ make|grep : 9.- $ sudo make install (this will install dillo, dpid, dpidc and the dpis) 10.- $ src/dillo -Reza
On Thu, 26 May 2011 03:34:06 -0400, reza farivar <rf.opensource@gmail.com> wrote:
Hi guys,
First post here, thanks for all your hard work on Dillo! I'm trying to compile and run dillo on Mac OS 10.6.7 (and report the bugs I find :D ). I followed instructions that Jorge sent me earlier, and it compiled without an error but a few warnings:
[...]
The good news is that Dillo runs. It also seems to eventually connect to websites, which is good news too.
But at least for me loading a page is a hit or miss experiment. Sometimes it waits for a long time (maybe 2-3 minutes) and couldn't connect, as if there was a DNS problem, other times it loads the same page easily in a few seconds. Here's the output from the terminal, after trying to connect to yahoo.com site unsuccessfully (waiting for a long time):
$ src/dillo paths: creating directory /Users/farivar2/.dillo. paths: Cannot open file '/Users/farivar2/.dillo/dillorc' paths: Using /usr/local/etc/dillo/dillorc paths: Cannot open file '/Users/farivar2/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Cookies: Created file: /Users/farivar2/.dillo/cookiesrc Disabling cookies. Nav_open_url: new url='about:splash' Nav_open_url: new url='http://www.yahoo.com' Dns_server [0]: www.yahoo.com is 209.191.122.70 69.147.125.65 67.195.160.76 Connecting to 209.191.122.70
and it almost hangs here. During this time the CPU utilization hovers around 134% (on a dual core machine), with 3 threads and 48MB of memory usage.
Is this behavior expected? Perhaps it's related to the warnings above? My guess is that it's either a DNS problem or an HTTP connection problem, resulting into a time-out case.
The warnings are just the compiler noting ambiguous syntax; they shouldn't affect the compilation beyond that. It could be in the DNS or HTTP code. It could also be FLTK. After you send an HTTP request, Dillo uses some FLTK functions to watch the socket for activity. I had a similar problem when I did the Windows port, and it turns out it wasn't Dillo, but buggy and broken FLTK code.
P.S.3 Are there reference rendering snapshots available? The Yahoo's web site and even Google's both render in a strange way (similar to the way links2 renders them). In fact the only website that I could get to render correctly is dillo.org (when it opens, other times it just decides not to open even after 5 minutes of waiting).
That's normal. Dillo still has extremely limited HTML support, so most pages do look rather funny (and it doesn't help that most sites don't recognize Dillo's user agent). A lot of sites, including Google, render better with a Mozilla/4.0 user agent. I actually have the Windows port default to "Mozilla/4.0 (compatible; Dillo 2.2)" for that reason. Cheers, ~Benjamin
reza wrote:
I'm trying to compile and run dillo on Mac OS 10.6.7 (and report the bugs I find :D ).
That's great!
http.c: In function ?Http_connect_queued_sockets?: http.c:177: warning: cast from pointer to integer of different size dialog.cc: In function ?int a_Dialog_choice5(const char*, const char*, const char*, const char*, const char*, const char*)?: dialog.cc:177: warning: suggest a space before ?;? or explicit braces around empty body in ?for? statement
Should be fixed now.
On Thu, May 26, 2011 at 9:33 AM, corvid <corvid@lavabit.com> wrote:
reza wrote:
I'm trying to compile and run dillo on Mac OS 10.6.7 (and report the bugs I find :D ).
That's great!
http.c: In function ?Http_connect_queued_sockets?: http.c:177: warning: cast from pointer to integer of different size dialog.cc: In function ?int a_Dialog_choice5(const char*, const char*, const char*, const char*, const char*, const char*)?: dialog.cc:177: warning: suggest a space before ?;? or explicit braces around empty body in ?for? statement
Should be fixed now.
Thanks, latest version indeed fixes the warning, but the connection problems remain.
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
reza wrote:
But at least for me loading a page is a hit or miss experiment. Sometimes it waits for a long time (maybe 2-3 minutes) and couldn't connect, as if there was a DNS problem, other times it loads the same page easily in a few seconds.
Just out of curiosity, does anything change if you configure with --disable-threaded-dns? I tried valgrind's helgrind tool a couple of weeks ago, and it complains and complains about threads, but I didn't know whether any of it had any significance.
On Thu, May 26, 2011 at 10:46 AM, corvid <corvid@lavabit.com> wrote:
But at least for me loading a page is a hit or miss experiment. Sometimes it waits for a long time (maybe 2-3 minutes) and couldn't connect, as if
reza wrote: there
was a DNS problem, other times it loads the same page easily in a few seconds.
Just out of curiosity, does anything change if you configure with --disable-threaded-dns?
I tried it, it feels it might have become better, but the problems still remain. If you don't want a touchy feely answer, then no, disable-threaded-dns didn't fix the problem.
I tried valgrind's helgrind tool a couple of weeks ago, and it complains and complains about threads, but I didn't know whether any of it had any significance.
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Hi, On Thu, May 26, 2011 at 02:34:06AM -0500, reza farivar wrote:
Hi guys,
First post here, thanks for all your hard work on Dillo! I'm trying to compile and run dillo on Mac OS 10.6.7 (and report the bugs I find :D ). I followed instructions that Jorge sent me earlier, and it compiled without an error but a few warnings:
$ make|grep : http.c: In function ?Http_connect_queued_sockets?: http.c:177: warning: cast from pointer to integer of different size dialog.cc: In function ?int a_Dialog_choice5(const char*, const char*, const char*, const char*, const char*, const char*)?: dialog.cc:177: warning: suggest a space before ?;? or explicit braces around empty body in ?for? statement make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all-am'.
The good news is that Dillo runs. It also seems to eventually connect to websites, which is good news too.
But at least for me loading a page is a hit or miss experiment. Sometimes it waits for a long time (maybe 2-3 minutes) and couldn't connect, as if there was a DNS problem, other times it loads the same page easily in a few seconds. Here's the output from the terminal, after trying to connect to yahoo.com site unsuccessfully (waiting for a long time):
$ src/dillo paths: creating directory /Users/farivar2/.dillo. paths: Cannot open file '/Users/farivar2/.dillo/dillorc' paths: Using /usr/local/etc/dillo/dillorc paths: Cannot open file '/Users/farivar2/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Cookies: Created file: /Users/farivar2/.dillo/cookiesrc Disabling cookies. Nav_open_url: new url='about:splash' Nav_open_url: new url='http://www.yahoo.com' Dns_server [0]: www.yahoo.com is 209.191.122.70 69.147.125.65 67.195.160.76 Connecting to 209.191.122.70
and it almost hangs here. During this time the CPU utilization hovers around 134% (on a dual core machine), with 3 threads and 48MB of memory usage.
The busy wait is a sign that something went really wrong. If it was a slow DNS, polling would not bump CPU usage.
Is this behavior expected?
Not at all.
Perhaps it's related to the warnings above?
Hardly.
My guess is that it's either a DNS problem or an HTTP connection problem, resulting into a time-out case.
A couple of years ago I tried dillo-2.x in a Mac (FLTK2), and it mainly worked (without the delays you describe). I did compile it with the X server stuff. I don't know whether it is possible to compile it natively. In what mode are you testing? (I ask because you said you couldn't compile dillo-2.x).
P.S. Sometimes it seems if I open another tab and enter another address it will help the first tab to load, but I can't get it to consistently act like that. Other times, it seems a tab can get stuck waiting for the host and can never load the page. It also seems adding http:// to the beggining of addresses help some times, but not consistently.
No. That's coincidence. Maybe there's a timing/sequence problem with the socket connection. If I only had a Mac here to try...
P.S.2 I checked my network connection with my other browser (chrome) and it has no problem connecting the mentioned websites.
If the other browser gets a quick DNS answer, then the problem is elsewhere.
P.S.3 Are there reference rendering snapshots available? The Yahoo's web site and even Google's both render in a strange way (similar to the way links2 renders them). In fact the only website that I could get to render correctly is dillo.org (when it opens, other times it just decides not to open even after 5 minutes of waiting).
Dillo doesn't have support for "floating elements" yet. The web has become full of them because of slow rendering of tables. Well, we're supposed to work on it in the near future. For the meanwhile, you'll see weird "unrolled" pages. -- Cheers Jorge.-
On Thu, May 26, 2011 at 11:15 AM, Jorge Arellano Cid <jcid@dillo.org> wrote:
Hi,
On Thu, May 26, 2011 at 02:34:06AM -0500, reza farivar wrote:
But at least for me loading a page is a hit or miss experiment. Sometimes
waits for a long time (maybe 2-3 minutes) and couldn't connect, as if
it there
was a DNS problem, other times it loads the same page easily in a few seconds. Here's the output from the terminal, after trying to connect to yahoo.com site unsuccessfully (waiting for a long time):
and it almost hangs here. During this time the CPU utilization hovers around 134% (on a dual core machine), with 3 threads and 48MB of memory usage.
The busy wait is a sign that something went really wrong. If it was a slow DNS, polling would not bump CPU usage.
So after installing the latest version of dillo (and disabling threaded DNS) I have no warnings but the problems still remain. I can consistently make the following scenario happen: After starting dillo, I open a new tab and enter a random website URL. Dillo gets into the busy wait loop (133% CPU usage, 3 threads) and doesn't load the page even after 10 minutes of waiting. Then I open another tab and enter another website (www.yahoo.com), and this makes both tabs to load their contents immediately. In general I never saw a connection problem when opening a link in a currently opened page. The problem always happens when entering a page URL manually in the address bar.
Is this behavior expected?
Not at all.
Perhaps it's related to the warnings above?
Hardly.
My guess is that it's either a DNS problem or an HTTP connection problem, resulting into a time-out case.
A couple of years ago I tried dillo-2.x in a Mac (FLTK2), and it mainly worked (without the delays you describe). I did compile it with the X server stuff. I don't know whether it is possible to compile it natively.
In what mode are you testing? (I ask because you said you couldn't compile dillo-2.x).
I am not running it with the X server. I think I have fltk1.3 compiled as native cocoa, the X11 server never opens up when running dillo, while other X11 apps (say links2) load it up. So I'm pretty sure I'm running it native.
P.S. Sometimes it seems if I open another tab and enter another address it will help the first tab to load, but I can't get it to consistently act like that. Other times, it seems a tab can get stuck waiting for the host and can never load the page. It also seems adding http:// to the beggining of addresses help some times, but not consistently.
No. That's coincidence. Maybe there's a timing/sequence problem with the socket connection. If I only had a Mac here to try...
Please see the scenario described above.
P.S.2 I checked my network connection with my other browser (chrome) and it has no problem connecting the mentioned websites.
If the other browser gets a quick DNS answer, then the problem is elsewhere.
P.S.3 Are there reference rendering snapshots available? The Yahoo's web site and even Google's both render in a strange way (similar to the way links2 renders them). In fact the only website that I could get to render correctly is dillo.org (when it opens, other times it just decides not to open even after 5 minutes of waiting).
Dillo doesn't have support for "floating elements" yet. The web has become full of them because of slow rendering of tables. Well, we're supposed to work on it in the near future. For the meanwhile, you'll see weird "unrolled" pages.
That good to hear. It seems you guys are now focused on this port to 1.3 for the time being? Is the floating elements next in line? Thanks, Reza
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Welcome, On Thu, May 26, 2011 at 02:34:06AM -0500, reza farivar wrote:
Hi guys,
First post here, thanks for all your hard work on Dillo! I'm trying to compile and run dillo on Mac OS 10.6.7 (and report the bugs I find :D ). I followed instructions that Jorge sent me earlier, and it compiled without an error but a few warnings:
$ make|grep : http.c: In function ?Http_connect_queued_sockets?: http.c:177: warning: cast from pointer to integer of different size dialog.cc: In function ?int a_Dialog_choice5(const char*, const char*, const char*, const char*, const char*, const char*)?: dialog.cc:177: warning: suggest a space before ?;? or explicit braces around empty body in ?for? statement make[2]: Nothing to be done for `all'. make[2]: Nothing to be done for `all-am'.
The good news is that Dillo runs. It also seems to eventually connect to websites, which is good news too.
I assume you compiled fltk with X11 backend. I'm also using this setup and it works more or less fine for me. For some sites though I see missing images or stylesheets. I didn't find time to investigate this further.
But at least for me loading a page is a hit or miss experiment. Sometimes it waits for a long time (maybe 2-3 minutes) and couldn't connect, as if there was a DNS problem, other times it loads the same page easily in a few seconds. Here's the output from the terminal, after trying to connect to yahoo.com site unsuccessfully (waiting for a long time):
I think logging the exact return codes and errno values of the network related syscalls might give us a clue why things go bad sometimes.
$ src/dillo paths: creating directory /Users/farivar2/.dillo. paths: Cannot open file '/Users/farivar2/.dillo/dillorc' paths: Using /usr/local/etc/dillo/dillorc paths: Cannot open file '/Users/farivar2/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Cookies: Created file: /Users/farivar2/.dillo/cookiesrc Disabling cookies. Nav_open_url: new url='about:splash' Nav_open_url: new url='http://www.yahoo.com' Dns_server [0]: www.yahoo.com is 209.191.122.70 69.147.125.65 67.195.160.76 Connecting to 209.191.122.70
and it almost hangs here. During this time the CPU utilization hovers around 134% (on a dual core machine), with 3 threads and 48MB of memory usage.
Ouch. I didn't see that yet.
Is this behavior expected? Perhaps it's related to the warnings above? My guess is that it's either a DNS problem or an HTTP connection problem, resulting into a time-out case.
It's certainly not expected.
P.S. Sometimes it seems if I open another tab and enter another address it will help the first tab to load, but I can't get it to consistently act like that. Other times, it seems a tab can get stuck waiting for the host and can never load the page. It also seems adding http:// to the beggining of addresses help some times, but not consistently.
P.S.2 I checked my network connection with my other browser (chrome) and it has no problem connecting the mentioned websites.
P.S.3 Are there reference rendering snapshots available? The Yahoo's web site and even Google's both render in a strange way (similar to the way links2 renders them). In fact the only website that I could get to render correctly is dillo.org (when it opens, other times it just decides not to open even after 5 minutes of waiting).
Well, that's life with dillo :) But we are working on improving compatibility.
P.S.4 Jorge's instructions to compile dillo-1.3 for Mac OS X are as follows:
1.- <install fltk-1.3-rc5 from fltk.org>
Did you take special care to compile fltk-1.3 with X11 backend? If not, you might run the dillo as native Cocoa application. In that case you were more successful then me. For me dillo with Cocoa-fltk starts, but does not load any remote pages. There seem to be severe issues with the way fltk handles events in the Cocoa case. Cheers, Johannes
On Thu, May 26, 2011 at 3:18 PM, Johannes Hofmann <Johannes.Hofmann@gmx.de>wrote:
The good news is that Dillo runs. It also seems to eventually connect to websites, which is good news too.
I assume you compiled fltk with X11 backend. I'm also using this setup and it works more or less fine for me. For some sites though I see missing images or stylesheets. I didn't find time to investigate this further.
No, I'm running it native on Mac OS X. I also have similar problems with missing images. Mostly when there is an image that has a link associated with it, the images don't load and only an empty frame is displayed. If I click inside the frame, it loads the image. The second click takes me to the target URL.
But at least for me loading a page is a hit or miss experiment. Sometimes
waits for a long time (maybe 2-3 minutes) and couldn't connect, as if
it there
was a DNS problem, other times it loads the same page easily in a few seconds. Here's the output from the terminal, after trying to connect to yahoo.com site unsuccessfully (waiting for a long time):
I think logging the exact return codes and errno values of the network related syscalls might give us a clue why things go bad sometimes.
How would I do that? Dillo definitely doesn't print them to the terminal from which I run it. I don't have anything from dillo on the console either (console looks at console.log, system.log, ~/Library/Logs, /Library/Logs, /var/logs).
and it almost hangs here. During this time the CPU utilization hovers around 134% (on a dual core machine), with 3 threads and 48MB of memory usage.
Ouch. I didn't see that yet.
It's definitely there, look at my other mail and the consistent scenario I can make.
Is this behavior expected? Perhaps it's related to the warnings above? My guess is that it's either a DNS problem or an HTTP connection problem, resulting into a time-out case.
It's certainly not expected.
P.S. Sometimes it seems if I open another tab and enter another address
will help the first tab to load, but I can't get it to consistently act
it like
that. Other times, it seems a tab can get stuck waiting for the host and can never load the page. It also seems adding http:// to the beggining of addresses help some times, but not consistently.
P.S.2 I checked my network connection with my other browser (chrome) and it has no problem connecting the mentioned websites.
P.S.3 Are there reference rendering snapshots available? The Yahoo's web site and even Google's both render in a strange way (similar to the way links2 renders them). In fact the only website that I could get to render correctly is dillo.org (when it opens, other times it just decides not to open even after 5 minutes of waiting).
Well, that's life with dillo :) But we are working on improving compatibility.
P.S.4 Jorge's instructions to compile dillo-1.3 for Mac OS X are as
follows:
1.- <install fltk-1.3-rc5 from fltk.org>
Did you take special care to compile fltk-1.3 with X11 backend? If not, you might run the dillo as native Cocoa application. In that case you were more successful then me. For me dillo with Cocoa-fltk starts, but does not load any remote pages. There seem to be severe issues with the way fltk handles events in the Cocoa case.
Hmm, maybe I should try recompiling fltk with X11 backend...But my current native version is so close to working with no problems...
Cheers, Johannes
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
reza wrote:
I also have similar problems with missing images. Mostly when there is an image that has a link associated with it, the images don't load and only an empty frame is displayed. If I click inside the frame, it loads the image. The second click takes me to the target URL.
In dillorc, you might try filter_auto_requests=allow_all
On Thu, May 26, 2011 at 03:42:04PM -0500, reza farivar wrote:
On Thu, May 26, 2011 at 3:18 PM, Johannes Hofmann
[...] Did you take special care to compile fltk-1.3 with X11 backend? If not, you might run the dillo as native Cocoa application. In that case you were more successful then me. For me dillo with Cocoa-fltk starts, but does not load any remote pages. There seem to be severe issues with the way fltk handles events in the Cocoa case.
Hmm, maybe I should try recompiling fltk with X11 backend...But my current native version is so close to working with no problems...
Yes, it's amazing how close it is from working native. Are plugins working OK? (e.g. can you browse the filesystem?) Do you know how to use gdb? It would be great to know in what functions the busy wait happens. It could be a timeout or anything. For this: gdb ./dillo <when locked on high CPU usage, hit Ctrl-c> bt This can hint us on what may be happening. -- Cheers Jorge.-
On Fri, May 27, 2011 at 10:28 AM, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Thu, May 26, 2011 at 03:42:04PM -0500, reza farivar wrote:
On Thu, May 26, 2011 at 3:18 PM, Johannes Hofmann
[...] Did you take special care to compile fltk-1.3 with X11 backend? If not, you might run the dillo as native Cocoa application. In that case you were more successful then me. For me dillo with Cocoa-fltk starts, but does not load any remote pages. There seem to be severe issues with the way fltk handles events in the Cocoa case.
Hmm, maybe I should try recompiling fltk with X11 backend...But my current native version is so close to working with no problems...
Yes, it's amazing how close it is from working native. Are plugins working OK? (e.g. can you browse the filesystem?)
Yes. Well, the only plugin I could see is the save button on the panel, and it can successfully navigate the filesystem and save a page correctly.
Do you know how to use gdb? It would be great to know in what functions the busy wait happens. It could be a timeout or anything. For this:
gdb ./dillo
<when locked on high CPU usage, hit Ctrl-c>
bt
Yes, Here's the result. I tried it a couple of times, and this looks like the culprit: #13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554 Those three lines are consistent everytime I break in GDB. The more detailed ones are different of course. Here's one, just in case: #0 0x00007fff87967dc5 in tiny_malloc_from_free_list () #1 0x00007fff87966fdd in szone_malloc_should_clear () #2 0x00007fff8799d32b in szone_memalign () #3 0x00007fff879a46eb in malloc_zone_memalign () #4 0x00007fff87376608 in CFSortIndexes () #5 0x00007fff87376480 in CFQSortArray () #6 0x00007fff87386ad2 in __CFRunLoopDoObservers () #7 0x00007fff87361da4 in CFRunLoopRunSpecific () #8 0x00007fff842457ee in RunCurrentEventLoopInMode () #9 0x00007fff842455f3 in ReceiveNextEventCommon () #10 0x00007fff842454ac in BlockUntilNextEventMatchingListInMode () #11 0x00007fff85739e64 in _DPSNextEvent () #12 0x00007fff857397a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554 #16 0x0000000100003a85 in main (argc=1, argv=0x7fff5fbff828) at dillo.cc:431 -Reza
This can hint us on what may be happening.
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Fri, 27 May 2011 13:38:43 -0400, reza farivar <rf.opensource@gmail.com> wrote:
Yes. Well, the only plugin I could see is the save button on the panel, and it can successfully navigate the filesystem and save a page correctly.
That one isn't a plugin, actually. Does the bookmarks button work? (Dillo's plugins right now are bookmarks, cookies, downloads, view source, and data/file/ftp/https URIs. They're not Flash-type graphical plugins, but things that really should be built into the browser.)
Yes, Here's the result. I tried it a couple of times, and this looks like the culprit:
#13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554
Those three lines are consistent everytime I break in GDB. The more detailed ones are different of course. Here's one, just in case:
#0 0x00007fff87967dc5 in tiny_malloc_from_free_list () #1 0x00007fff87966fdd in szone_malloc_should_clear () #2 0x00007fff8799d32b in szone_memalign () #3 0x00007fff879a46eb in malloc_zone_memalign () #4 0x00007fff87376608 in CFSortIndexes () #5 0x00007fff87376480 in CFQSortArray () #6 0x00007fff87386ad2 in __CFRunLoopDoObservers () #7 0x00007fff87361da4 in CFRunLoopRunSpecific () #8 0x00007fff842457ee in RunCurrentEventLoopInMode () #9 0x00007fff842455f3 in ReceiveNextEventCommon () #10 0x00007fff842454ac in BlockUntilNextEventMatchingListInMode () #11 0x00007fff85739e64 in _DPSNextEvent () #12 0x00007fff857397a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554 #16 0x0000000100003a85 in main (argc=1, argv=0x7fff5fbff828) at dillo.cc:431
It looks like the problem's somewhere in FLTK. I'll take a look and see what I can find. Cheers, ~Benjamin
On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson <obeythepenguin@gmail.com
wrote:
On Fri, 27 May 2011 13:38:43 -0400, reza farivar <rf.opensource@gmail.com> wrote:
Yes. Well, the only plugin I could see is the save button on the panel,
and it can successfully navigate the filesystem and save a page correctly.
That one isn't a plugin, actually. Does the bookmarks button work?
Yes, bookmarks work. (This is a bit of strange implementation of bookmarks, no? took me a bit to find out difference of section and item)
(Dillo's plugins right now are bookmarks, cookies, downloads, view source, and data/file/ftp/https URIs. They're not Flash-type graphical plugins, but things that really should be built into the browser.)
View source works too, and chances are cookies are working (otherwise many servers would complain). I cant find the rest (downloads, etc.)
Yes, Here's the result. I tried it a couple of times, and this looks like
the culprit:
#13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554
Those three lines are consistent everytime I break in GDB. The more detailed ones are different of course. Here's one, just in case:
#0 0x00007fff87967dc5 in tiny_malloc_from_free_list () #1 0x00007fff87966fdd in szone_malloc_should_clear () #2 0x00007fff8799d32b in szone_memalign () #3 0x00007fff879a46eb in malloc_zone_memalign () #4 0x00007fff87376608 in CFSortIndexes () #5 0x00007fff87376480 in CFQSortArray () #6 0x00007fff87386ad2 in __CFRunLoopDoObservers () #7 0x00007fff87361da4 in CFRunLoopRunSpecific () #8 0x00007fff842457ee in RunCurrentEventLoopInMode () #9 0x00007fff842455f3 in ReceiveNextEventCommon () #10 0x00007fff842454ac in BlockUntilNextEventMatchingListInMode () #11 0x00007fff85739e64 in _DPSNextEvent () #12 0x00007fff857397a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554 #16 0x0000000100003a85 in main (argc=1, argv=0x7fff5fbff828) at dillo.cc:431
It looks like the problem's somewhere in FLTK. I'll take a look and see what I can find.
Cheers, ~Benjamin
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote:
On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson <obeythepenguin@gmail.com
wrote:
On Fri, 27 May 2011 13:38:43 -0400, reza farivar <rf.opensource@gmail.com> wrote:
Yes. Well, the only plugin I could see is the save button on the panel,
and it can successfully navigate the filesystem and save a page correctly.
That one isn't a plugin, actually. Does the bookmarks button work?
Yes, bookmarks work. (This is a bit of strange implementation of bookmarks, no? took me a bit to find out difference of section and item)
Good! If you can see the html page from the bookmarks, it means the whole dpi framework is working on Mac; they communicate using sockets. So it seems the main thing pending is socket support in fl_wait for Mac (see my previous email).
View source works too, and chances are cookies are working (otherwise many servers would complain). I cant find the rest (downloads, etc.)
If one works, all of them work. -- Cheers Jorge.-
On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson < obeythepenguin@gmail.com
wrote:
On Fri, 27 May 2011 13:38:43 -0400, reza farivar < rf.opensource@gmail.com> wrote:
Yes. Well, the only plugin I could see is the save button on the
On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: panel,
and it can successfully navigate the filesystem and save a page correctly.
That one isn't a plugin, actually. Does the bookmarks button work?
Yes, bookmarks work. (This is a bit of strange implementation of bookmarks, no? took me a bit to find out difference of section and item)
Good!
If you can see the html page from the bookmarks, it means the whole dpi framework is working on Mac; they communicate using sockets.
So it seems the main thing pending is socket support in fl_wait for Mac (see my previous email).
Yes, I also think it's the source of this problem (see my other email). But what really perplexes me is that this happens only when I enter a URL manually. When I follow links from one page to another it never happens. Are you guys using different (FLTK) functions when opening a new page or following a links (whether in the same tab or in a new tab)? And it seems that as Dillo "warms up" I get less of this problem...
View source works too, and chances are cookies are working (otherwise many servers would complain). I cant find the rest (downloads, etc.)
If one works, all of them work.
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Fri, May 27, 2011 at 03:25:32PM -0500, reza farivar wrote:
On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson < obeythepenguin@gmail.com
wrote:
On Fri, 27 May 2011 13:38:43 -0400, reza farivar < rf.opensource@gmail.com> wrote:
Yes. Well, the only plugin I could see is the save button on the
On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: panel,
and it can successfully navigate the filesystem and save a page correctly.
That one isn't a plugin, actually. Does the bookmarks button work?
Yes, bookmarks work. (This is a bit of strange implementation of bookmarks, no? took me a bit to find out difference of section and item)
Good!
If you can see the html page from the bookmarks, it means the whole dpi framework is working on Mac; they communicate using sockets.
So it seems the main thing pending is socket support in fl_wait for Mac (see my previous email).
Yes, I also think it's the source of this problem (see my other email).
But what really perplexes me is that this happens only when I enter a URL manually. When I follow links from one page to another it never happens. Are you guys using different (FLTK) functions when opening a new page or following a links (whether in the same tab or in a new tab)?
No, but when you hit ENTER, FLTK has a chance to queue events and zero-wait timeouts for the widget callback and necessary stuff. OTOH, clicking a link goes another path (inside dillo).
And it seems that as Dillo "warms up" I get less of this problem...
Timimg issues are moody. e.g. Have you tried dillo listening a good mp3? :-) BTW, good you asked Manolo G. (FWIW, FLTK2 has code for socket events in Mac). -- Cheers Jorge.-
On Fri, 27 May 2011 16:53:40 -0400, Jorge Arellano Cid <jcid@dillo.org> wrote:
(FWIW, FLTK2 has code for socket events in Mac).
Might be worth backporting, assuming 2.x's implementation is halfway decent... though the Windows version was so broken, I had to backport from 1.3! Anyway, I think I remember that part of the code, so I'll be happy to provide whatever help I can. I do remember fl_wait is probably the nastiest function I've ever worked on, though the select call is the very least of its problems. ~Benjamin
On Fri, May 27, 2011 at 3:53 PM, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Fri, May 27, 2011 at 03:25:32PM -0500, reza farivar wrote:
On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson < obeythepenguin@gmail.com
wrote:
On Fri, 27 May 2011 13:38:43 -0400, reza farivar < rf.opensource@gmail.com> wrote:
Yes. Well, the only plugin I could see is the save button on the
On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: panel,
and it can successfully navigate the filesystem and save a page correctly.
That one isn't a plugin, actually. Does the bookmarks button work?
Yes, bookmarks work. (This is a bit of strange implementation of bookmarks, no? took me a bit to find out difference of section and item)
Good!
If you can see the html page from the bookmarks, it means the whole dpi framework is working on Mac; they communicate using sockets.
So it seems the main thing pending is socket support in fl_wait for Mac (see my previous email).
Yes, I also think it's the source of this problem (see my other email).
But what really perplexes me is that this happens only when I enter a URL manually. When I follow links from one page to another it never happens. Are you guys using different (FLTK) functions when opening a new page or following a links (whether in the same tab or in a new tab)?
No, but when you hit ENTER, FLTK has a chance to queue events and zero-wait timeouts for the widget callback and necessary stuff. OTOH, clicking a link goes another path (inside dillo).
That can explain it. Well, then your patch might have a chance, if it's not really a socket issue. I'll give it a try later tonight.
And it seems that as Dillo "warms up" I get less of this problem...
Timimg issues are moody. e.g. Have you tried dillo listening a good mp3? :-)
:-)
BTW, good you asked Manolo G. (FWIW, FLTK2 has code for socket events in Mac).
Yes, I found it in FLTK2. It turns out fl_wait in FLTK2 (in
src/osx/run.cxx) is a complex function, while the equivalent incomplete function in 1.3 only a couple of lines. I think it's best let FLTK guys handle it. --
Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Fri, May 27, 2011 at 3:53 PM, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Fri, May 27, 2011 at 03:25:32PM -0500, reza farivar wrote:
On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson < obeythepenguin@gmail.com
wrote:
On Fri, 27 May 2011 13:38:43 -0400, reza farivar < rf.opensource@gmail.com> wrote:
Yes. Well, the only plugin I could see is the save button on the
On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: panel,
and it can successfully navigate the filesystem and save a page correctly.
That one isn't a plugin, actually. Does the bookmarks button work?
Yes, bookmarks work. (This is a bit of strange implementation of bookmarks, no? took me a bit to find out difference of section and item)
Good!
If you can see the html page from the bookmarks, it means the whole dpi framework is working on Mac; they communicate using sockets.
So it seems the main thing pending is socket support in fl_wait for Mac (see my previous email).
Yes, I also think it's the source of this problem (see my other email).
But what really perplexes me is that this happens only when I enter a URL manually. When I follow links from one page to another it never happens. Are you guys using different (FLTK) functions when opening a new page or following a links (whether in the same tab or in a new tab)?
No, but when you hit ENTER, FLTK has a chance to queue events and zero-wait timeouts for the widget callback and necessary stuff. OTOH, clicking a link goes another path (inside dillo).
Can you point me to parts of code for either of these two code paths? Filename / line number should suffice.
And it seems that as Dillo "warms up" I get less of this problem...
Timimg issues are moody. e.g. Have you tried dillo listening a good mp3? :-)
BTW, good you asked Manolo G. (FWIW, FLTK2 has code for socket events in Mac).
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Well after 2 days of chasing the non-connection bug, I'm still not successful in locating the bug. But first a few points: 1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I found this myself and later Manolo verified it. The comment that Jorge mentioned is a leftover, but the code is there. In fact it runs in a pthread, and the whole system wouldn't work without it anyway. 2. So I'm now convinced the problem is somewhere in Dillo. Here is what I have nailed it down to so far: It seems to me that the problem might have to do with "repush". I run the program as: $src/dillo | grep Nav_, and I can get no connection regardless of the websites until I enter a URL that forces a repush. I have a list of websites that do not entice a repush (some of the times): www.yahoo.com, www.google.com, http://www.maketemplate.com/htmlgenerator/htmlout.php autos.yahoo.com, and as long as I keep entering any of these addresses after a fresh start and I don't see a repush message in terminal, I will get nothing in my tabs. As soon as I enter a URL that does entice a repush, the whole system works, including the previous blocked tabs. If later on again a tab doesn't load up, I can make the system work by opening other tabs and entering URLs until a repush happens. So, what is this repush business? And do you think it can have anything to do with the bug I'm seeing? By the way, the busy wait issue seems to be a different bug and just happens to coincide. No matter which website I enter, the first tab (whether I enter URL manually or on command line) never connects and always forces a busy wait. As soon as I open another tab and enter any URL, regardless of whether it will do a repush and open the clog or not, the busy-wait ends. P.S. In my opinion (and ignoring this pesky bug) the single most important feature lacking in dillo is support for floating elements. As soon as we have it, dillo is as good as NetSurf (http://www.netsurf-browser.org/) in functionality with half the memory footprint. As far as I can tell NetSurf is the current champ of low resource + good enough functionality, while IMHO dillo has more potential. -Reza On Fri, May 27, 2011 at 7:11 PM, reza farivar <rf.opensource@gmail.com>wrote:
On Fri, May 27, 2011 at 3:53 PM, Jorge Arellano Cid <jcid@dillo.org>wrote:
On Fri, May 27, 2011 at 03:25:32PM -0500, reza farivar wrote:
On Fri, May 27, 2011 at 3:18 PM, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Fri, May 27, 2011 at 12:46 PM, Benjamin Johnson < obeythepenguin@gmail.com
wrote:
On Fri, 27 May 2011 13:38:43 -0400, reza farivar < rf.opensource@gmail.com> wrote:
Yes. Well, the only plugin I could see is the save button on the
On Fri, May 27, 2011 at 01:53:08PM -0500, reza farivar wrote: panel,
> and > it can successfully navigate the filesystem and save a page correctly. >
That one isn't a plugin, actually. Does the bookmarks button work?
Yes, bookmarks work. (This is a bit of strange implementation of bookmarks, no? took me a bit to find out difference of section and item)
Good!
If you can see the html page from the bookmarks, it means the whole dpi framework is working on Mac; they communicate using sockets.
So it seems the main thing pending is socket support in fl_wait for Mac (see my previous email).
Yes, I also think it's the source of this problem (see my other email).
But what really perplexes me is that this happens only when I enter a URL manually. When I follow links from one page to another it never happens. Are you guys using different (FLTK) functions when opening a new page or following a links (whether in the same tab or in a new tab)?
No, but when you hit ENTER, FLTK has a chance to queue events and zero-wait timeouts for the widget callback and necessary stuff. OTOH, clicking a link goes another path (inside dillo).
Can you point me to parts of code for either of these two code paths? Filename / line number should suffice.
And it seems that as Dillo "warms up" I get less of this problem...
Timimg issues are moody. e.g. Have you tried dillo listening a good mp3? :-)
BTW, good you asked Manolo G. (FWIW, FLTK2 has code for socket events in Mac).
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Mon, 30 May 2011 06:40:53 -0400, reza farivar <rf.opensource@gmail.com> wrote:
So, what is this repush business? And do you think it can have anything to do with the bug I'm seeing?
IIRC, a "repush" is where it reloads the page from cache. I think it does that, for example, when it loads a style sheet. Come to think of it, try turning CSS and images off (under the Tools menu) and see what happens. I don't know if it will make any difference, but if it does, then there might be something going on in that code.
P.S. In my opinion (and ignoring this pesky bug) the single most important feature lacking in dillo is support for floating elements. As soon as we have it, dillo is as good as NetSurf (http://www.netsurf-browser.org/) in functionality with half the memory footprint. As far as I can tell NetSurf is the current champ of low resource + good enough functionality, while IMHO dillo has more potential.
Agreed. (My favorite thing about Dillo: what other web browser in 2011 still fits on one floppy disk?) Cheers, ~Benjamin
On Mon, May 30, 2011 at 6:43 AM, Benjamin Johnson <obeythepenguin@gmail.com>wrote:
On Mon, 30 May 2011 06:40:53 -0400, reza farivar <rf.opensource@gmail.com> wrote:
So, what is this repush business? And do you think it can have anything to
do with the bug I'm seeing?
IIRC, a "repush" is where it reloads the page from cache. I think it does that, for example, when it loads a style sheet.
Come to think of it, try turning CSS and images off (under the Tools menu) and see what happens. I don't know if it will make any difference, but if it does, then there might be something going on in that code.
Excellent suggestion Benjamin! It didn't work from the tools menu, but once I added load_stylesheets=NO parse_embedded_css=NO to dillorc and make clean;make again, it's now much much better! Aside from the first tab (see below), I never have any connections problems now. As I was guessing, the busy wait is still there ONLY for the first tab (whether entered from command line or in the browser). But now any second tab will get stuff working, and I never see a page not loading again. So for now I'm assuming this busy wait of the first tab is an orthogonal issue and leave it alone (for now I can launch dillo as $src/dillo www.yahoo.com www.google.com and they both load fine). So, it seems the bug stems somewhere in the stylesheets support, and perhaps the repush issue was pointing to this as well. Any suggestions what to look for next?
P.S. In my opinion (and ignoring this pesky bug) the single most important
feature lacking in dillo is support for floating elements. As soon as we have it, dillo is as good as NetSurf (http://www.netsurf-browser.org/) in functionality with half the memory footprint. As far as I can tell NetSurf is the current champ of low resource + good enough functionality, while IMHO dillo has more potential.
Agreed. (My favorite thing about Dillo: what other web browser in 2011 still fits on one floppy disk?)
Cheers, ~Benjamin
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
reza wrote:
As I was guessing, the busy wait is still there ONLY for the first tab (whether entered from command line or in the browser). But now any second tab will get stuff working, and I never see a page not loading again. So for now I'm assuming this busy wait of the first tab is an orthogonal issue and leave it alone (for now I can launch dillo as $src/dillo www.yahoo.com www.google.com and they both load fine).
So, it seems the bug stems somewhere in the stylesheets support, and perhaps the repush issue was pointing to this as well.
Do you have any problems when repushes are triggered by meta tags changing the character encoding (Html_tag_open_meta() )?
On Mon, May 30, 2011 at 3:38 PM, corvid <corvid@lavabit.com> wrote:
As I was guessing, the busy wait is still there ONLY for the first tab (whether entered from command line or in the browser). But now any second tab will get stuff working, and I never see a page not loading again. So for now I'm assuming this busy wait of the first tab is an orthogonal issue and leave it alone (for now I can launch dillo as $src/dillo www.yahoo.com www.google.com and they both load fine).
So, it seems the bug stems somewhere in the stylesheets support, and
reza wrote: perhaps
the repush issue was pointing to this as well.
Do you have any problems when repushes are triggered by meta tags changing the character encoding (Html_tag_open_meta() )?
There is no problem with them with the CSS support disabled. I can open a page with META and charset in the HEAD ( http://www.spartacus.schoolnet.co.uk/USAPstieglitz.htm), and it opens fine. I successfully see ">>>> a_Nav_repush <<<<" in the logs. With CSS support enabled, the same page with META (and a bit of CSS) does not load. Interestingly, loading it DOES NOT force a repush, even though it should since that page has <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> Note: seeing a ">>>> a_Nav_repush <<<<" in the logs is more of an indication that something good happened which opens the clog. So the question is, what happens during CSS parsing that forces a repush? Or looking at the problem the other way, why disabling the CSS support makes pages work without a repush, while having the CSS clogs them until something happens that a repush takes place?
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Hi Reza, On Mon, May 30, 2011 at 03:03:54PM -0500, reza farivar wrote:
[...] Any suggestions what to look for next?
Please try vanilla dillo with fltk-1.3 svn version r.8771. Or if you don't know how to get it from svn, patch your rc7 with this: http://fltk.org/newsgroups.php?s6029+gfltk.commit+v6048+T0 The FLTK devs are expecting our answer to close the issue. -- Cheers Jorge.-
On Tue, May 31, 2011 at 10:08:47AM -0400, Jorge Arellano Cid wrote:
Hi Reza,
On Mon, May 30, 2011 at 03:03:54PM -0500, reza farivar wrote:
[...] Any suggestions what to look for next?
Please try vanilla dillo with fltk-1.3 svn version r.8771.
Or if you don't know how to get it from svn, patch your rc7 with this: ^^^ typo here, should read "rc6"
http://fltk.org/newsgroups.php?s6029+gfltk.commit+v6048+T0
The FLTK devs are expecting our answer to close the issue.
-- Cheers Jorge.-
Woohoo!!! r.8771 fixes all problems! Thanks Jorge! On Tue, May 31, 2011 at 9:08 AM, Jorge Arellano Cid <jcid@dillo.org> wrote:
Hi Reza,
On Mon, May 30, 2011 at 03:03:54PM -0500, reza farivar wrote:
[...] Any suggestions what to look for next?
Please try vanilla dillo with fltk-1.3 svn version r.8771.
Or if you don't know how to get it from svn, patch your rc7 with this:
http://fltk.org/newsgroups.php?s6029+gfltk.commit+v6048+T0
The FLTK devs are expecting our answer to close the issue.
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Jorge, Good job identifying the problem. Based on the symptoms it looked too much like the bug is in Dillo. I just found out your patch ( http://www.fltk.org/str.php?L2652+P0+S-2+C0+I0+E0+Q2652) and I'm impressed on how you found the issue. I should also add that now the rendering looks better than before. I'll install dillo on my linux box to cross compare now, but it's great that nasty bug is resolved. -Reza On Wed, Jun 1, 2011 at 12:52 AM, reza farivar <rf.opensource@gmail.com>wrote:
Woohoo!!!
r.8771 fixes all problems!
Thanks Jorge!
On Tue, May 31, 2011 at 9:08 AM, Jorge Arellano Cid <jcid@dillo.org>wrote:
Hi Reza,
On Mon, May 30, 2011 at 03:03:54PM -0500, reza farivar wrote:
[...] Any suggestions what to look for next?
Please try vanilla dillo with fltk-1.3 svn version r.8771.
Or if you don't know how to get it from svn, patch your rc7 with this:
http://fltk.org/newsgroups.php?s6029+gfltk.commit+v6048+T0
The FLTK devs are expecting our answer to close the issue.
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Wed, Jun 01, 2011 at 01:09:37AM -0500, reza farivar wrote:
Jorge,
Good job identifying the problem. Based on the symptoms it looked too much like the bug is in Dillo. I just found out your patch ( http://www.fltk.org/str.php?L2652+P0+S-2+C0+I0+E0+Q2652)
:) That's experience. Experience: what you learn after years of making mistakes ;-)
and I'm impressed on how you found the issue.
I could elaborate a bit on it, but don't want to sound boring.
I should also add that now the rendering looks better than before. I'll install dillo on my linux box to cross compare now, but it's great that nasty bug is resolved.
Yes, and we can also claim native compatibility with OS X. -- Cheers Jorge.-
On Mon, May 30, 2011 at 05:40:53AM -0500, reza farivar wrote:
Well after 2 days of chasing the non-connection bug, I'm still not successful in locating the bug. But first a few points:
1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I found this myself and later Manolo verified it. The comment that Jorge mentioned is a leftover, but the code is there. In fact it runs in a pthread, and the whole system wouldn't work without it anyway.
What did Manolo answer exactly?
2. So I'm now convinced the problem is somewhere in Dillo.
What did convince you? -- Cheers Jorge.-
On Mon, May 30, 2011 at 12:32 PM, Jorge Arellano Cid <jcid@dillo.org> wrote:
Well after 2 days of chasing the non-connection bug, I'm still not successful in locating the bug. But first a few points:
1. Mac-Fltk 1.3 indeed contains code for "select"ing socket events. I found this myself and later Manolo verified it. The comment that Jorge mentioned is a leftover, but the code is there. In fact it runs in a pthread, and
On Mon, May 30, 2011 at 05:40:53AM -0500, reza farivar wrote: the
whole system wouldn't work without it anyway.
What did Manolo answer exactly?
Here's what I asked and his answer: "
Hi Manolo,
I'm working with "Dillo browser" people to get their browser, which uses FLTK 1.3, to compile and run on Mac OS X.
We have come across a bug in which the browser waits forever in a busy loop waiting for something from a connecting socket, which seems to come from FLTK.
Specifically, during the busy wait period it seems the program is stuck in fl_mac_flush_and_wait() from FL_cocoa.mm.
fl_mac_flush_and_wait in turn calls fl_wait(). I noticed that you have left a comment on top of fl_wait() mentioning:
\todo there is no socket handling in this code whatsoever
I also checked the fl_wait function for the unix versions in FL_x.cxx, and in there the function issues the "select" system call, while in the mac function it seems it's just a timeout loop?
Can you please verify if this is indeed a missing functionality waiting to be fixed? Is there a quick fix?
Hi Reza, I have no idea why this comment is there. It was in the Carbon version, and I didn't remove it. I know that Fl::add_fd() on a pseudoterminal works correctly (I use that in my app). I have checked with the button demo program (after changing #if 0 into #if 1) that Fl::add_fd() also works on stdin. Thus, my idea is that there was no missing functionality. But I may be wrong, and you may have discovered a bug. You would then have to file an STR in FLTK for that, and describe the problem as accurately as possible. Best wishes, Manolo ============================================================== Hi Reza, Below is the logical flow that handles file descriptors declared to FLTK with Fl::add_fd(). It is identical in essence to what it was during the Carbon era. The only change is that events are created, queued, and fetched the Cocoa way. in main thread: fl_mac_flush_and_wait fl_wait do_queued_events //start a thread devoted to fd handling: if ( dataready.GetNfds() ) dataready.StartThread(); //continue below in fd-handling thread: This thread runs DataReady::DataReadyThread() that does select() on current fd's. When data is ready, DataReadyThread() creates an application-defined event of subtype FLTKDataReadyEvent, puts it in the event queue, and the thread finishes. in main thread (continued): //the next event is fetched from the event queue: NSEvent *event = [NSApp nextEventMatchingMask:NSAnyEventMask ... //and the sendEvent function is called: [FLApplication sendEvent:event]; //in: (void)sendEvent:(NSEvent *)theEvent if the event type is NSApplicationDefined and the subtype is FLTKDataReadyEvent, call processFLTKEvent() call DataReady::HandleData() call the fd callback to process this data. Hoping this helps. Manolo =================================================================== Hi Reza, The threads demo program runs well on Mac OS. This shows that Fl::add_fd() is also correct for a pipe, as used in this program. I never tested a socket, though. "
2. So I'm now convinced the problem is somewhere in Dillo.
What did convince you?
The demo programs of FLTK work fine, and FLTK does issue a "select" system call in a thread. See in FLTK: src/Fl_cocoa.c, lines 364 to 409, and Manolo's comments above. On the other hand it seems the bug has to do with the contents of the pages being loaded. If the contents are such that it doesn't create conditions for a repush, things get stuck. Otherwise If the contents do force a repush in dillo, the other previous tabs start to load their contents. Finally as I mentioned earlier it seems the busy loop is an orthogonal issue, which always happens for the first tab, no matter what the contents are. It is probably a red herring, which sent us to the path of looking at fl_mac_flush_and_wait. But as soon as I open a second tab and enter a URL the busy wait stops and never happens again. But since the non-connection issue remains for the rest of the tabs, it makes me believe the non-connection bug is a separate issue to the busy wait of first tab, and has to do with conditions of a repush.
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Fri, 27 May 2011 13:38:43 -0400, reza farivar <rf.opensource@gmail.com> wrote:
Yes, Here's the result. I tried it a couple of times, and this looks like the culprit:
#13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554
Those three lines are consistent everytime I break in GDB. The more detailed ones are different of course. Here's one, just in case:
#0 0x00007fff87967dc5 in tiny_malloc_from_free_list () #1 0x00007fff87966fdd in szone_malloc_should_clear () #2 0x00007fff8799d32b in szone_memalign () #3 0x00007fff879a46eb in malloc_zone_memalign () #4 0x00007fff87376608 in CFSortIndexes () #5 0x00007fff87376480 in CFQSortArray () #6 0x00007fff87386ad2 in __CFRunLoopDoObservers () #7 0x00007fff87361da4 in CFRunLoopRunSpecific () #8 0x00007fff842457ee in RunCurrentEventLoopInMode () #9 0x00007fff842455f3 in ReceiveNextEventCommon () #10 0x00007fff842454ac in BlockUntilNextEventMatchingListInMode () #11 0x00007fff85739e64 in _DPSNextEvent () #12 0x00007fff857397a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554 #16 0x0000000100003a85 in main (argc=1, argv=0x7fff5fbff828) at dillo.cc:431
I did a bit more looking. Here's style.hh: http://hg.dillo.org/dillo_port1.3/file/b24e8b62bef3/dw/style.hh Line 554 of style.hh is Tooltip (const char *text): TooltipAttrs(text) { refCount = 0; } Then I found this recent thread on FLTK's mailing list: http://comments.gmane.org/gmane.comp.lib.fltk.general/23464 It seems kind of far-fetched, but this leads me to think there's something going on with tooltips -- some bug in the code might be corrupting memory or something. Does adding "show_tooltip=NO" to your dillorc have any effect? ~Benjamin
On Fri, May 27, 2011 at 1:04 PM, Benjamin Johnson <obeythepenguin@gmail.com>wrote:
On Fri, 27 May 2011 13:38:43 -0400, reza farivar <rf.opensource@gmail.com> wrote:
Yes, Here's the result. I tried it a couple of times, and this looks like
the culprit:
#13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554
Those three lines are consistent everytime I break in GDB. The more detailed ones are different of course. Here's one, just in case:
#0 0x00007fff87967dc5 in tiny_malloc_from_free_list () #1 0x00007fff87966fdd in szone_malloc_should_clear () #2 0x00007fff8799d32b in szone_memalign () #3 0x00007fff879a46eb in malloc_zone_memalign () #4 0x00007fff87376608 in CFSortIndexes () #5 0x00007fff87376480 in CFQSortArray () #6 0x00007fff87386ad2 in __CFRunLoopDoObservers () #7 0x00007fff87361da4 in CFRunLoopRunSpecific () #8 0x00007fff842457ee in RunCurrentEventLoopInMode () #9 0x00007fff842455f3 in ReceiveNextEventCommon () #10 0x00007fff842454ac in BlockUntilNextEventMatchingListInMode () #11 0x00007fff85739e64 in _DPSNextEvent () #12 0x00007fff857397a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554 #16 0x0000000100003a85 in main (argc=1, argv=0x7fff5fbff828) at dillo.cc:431
I did a bit more looking. Here's style.hh: http://hg.dillo.org/dillo_port1.3/file/b24e8b62bef3/dw/style.hh
Line 554 of style.hh is Tooltip (const char *text): TooltipAttrs(text) { refCount = 0; }
Then I found this recent thread on FLTK's mailing list: http://comments.gmane.org/gmane.comp.lib.fltk.general/23464
It seems kind of far-fetched, but this leads me to think there's something going on with tooltips -- some bug in the code might be corrupting memory or something. Does adding "show_tooltip=NO" to your dillorc have any effect?
Unfortunately not, didn't solve the problem.
~Benjamin
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Fri, May 27, 2011 at 3:11 PM, Benjamin Johnson <obeythepenguin@gmail.com>wrote:
On Fri, 27 May 2011 14:59:01 -0400, reza farivar <rf.opensource@gmail.com> wrote:
Unfortunately not, didn't solve the problem.
Well, there's my crazy guess, anyway. Does GDB still give the same output?
Yes, very same output.
(It's definitely worth trying the patch Jorge suggested, too)
I'll wait a few hours to see if I get a response back from Manolo, otherwise I'll give his patch a try. However, FL_wait in linux version of FLTK-1.3 uses "select" which can return socket events, while the mac version doesn't have that.
~Benjamin
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
On Fri, 27 May 2011 16:19:23 -0400, reza farivar <rf.opensource@gmail.com> wrote:
I'll wait a few hours to see if I get a response back from Manolo, otherwise I'll give his patch a try. However, FL_wait in linux version of FLTK-1.3 uses "select" which can return socket events, while the mac version doesn't have that.
That's almost certainly it. I should have looked closer at that part of the file, really, since that's where a lot of Windows problems were, too -- it seems FLTK really can't be bothered testing this stuff on non-Linux platforms. One last thing you could try while you're waiting: force it to use Fl_mac.cxx instead of Fl_cocoa.mm, and compile FLTK and Dillo as 32-bit. Offhand I have no idea how to do that, since I don't own a Mac, but I understand 32-bit apps can still use the old Carbon API (unlike 64-bit, which have to use Cocoa). ~Benjamin
On Fri, May 27, 2011 at 12:38:43PM -0500, reza farivar wrote:
On Fri, May 27, 2011 at 10:28 AM, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Thu, May 26, 2011 at 03:42:04PM -0500, reza farivar wrote:
On Thu, May 26, 2011 at 3:18 PM, Johannes Hofmann
[...] Did you take special care to compile fltk-1.3 with X11 backend? If not, you might run the dillo as native Cocoa application. In that case you were more successful then me. For me dillo with Cocoa-fltk starts, but does not load any remote pages. There seem to be severe issues with the way fltk handles events in the Cocoa case.
Hmm, maybe I should try recompiling fltk with X11 backend...But my current native version is so close to working with no problems...
Yes, it's amazing how close it is from working native. Are plugins working OK? (e.g. can you browse the filesystem?)
Yes. Well, the only plugin I could see is the save button on the panel, and it can successfully navigate the filesystem and save a page correctly.
Do you know how to use gdb? It would be great to know in what functions the busy wait happens. It could be a timeout or anything. For this:
gdb ./dillo
<when locked on high CPU usage, hit Ctrl-c>
bt
Yes, Here's the result. I tried it a couple of times, and this looks like the culprit:
#13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554
This gets us on track! Dig... In fltk-1.3-rc6, Fl_mac.cxx, it says: <quote> /** * This public function handles all events. It wait a maximum of * 'time' secods for an event. This version returns 1 if events * other than the timeout timer were processed. * * \todo there is no socket handling in this code whatsoever */ int fl_wait( double time ) { do_queued_events( time ); return (got_events); } </quote> so it looks like when there're sockets to watch, there's a busy wait (because it sometimes work). This is for the FLTK devs to answer. As a wild shot I'd try: Fl_cocoa.mm:680 - time_to_wait = 0.0; + time_to_wait = 0.2; Or set it to always 0.1 and see what happens. -- Cheers Jorge.-
On Fri, May 27, 2011 at 1:08 PM, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Fri, May 27, 2011 at 12:38:43PM -0500, reza farivar wrote:
On Fri, May 27, 2011 at 10:28 AM, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Thu, May 26, 2011 at 03:42:04PM -0500, reza farivar wrote:
On Thu, May 26, 2011 at 3:18 PM, Johannes Hofmann
[...] Did you take special care to compile fltk-1.3 with X11 backend? If not, you might run the dillo as native Cocoa application. In that case you were more successful then me. For me dillo with Cocoa-fltk starts, but does not load any remote pages. There seem to be severe issues with the way fltk handles events in the Cocoa case.
Hmm, maybe I should try recompiling fltk with X11 backend...But my current native version is so close to working with no problems...
Yes, it's amazing how close it is from working native. Are plugins working OK? (e.g. can you browse the filesystem?)
Yes. Well, the only plugin I could see is the save button on the panel, and it can successfully navigate the filesystem and save a page correctly.
Do you know how to use gdb? It would be great to know in what functions the busy wait happens. It could be a timeout or anything. For this:
gdb ./dillo
<when locked on high CPU usage, hit Ctrl-c>
bt
Yes, Here's the result. I tried it a couple of times, and this looks like the culprit:
#13 0x000000010007d373 in do_queued_events () at style.hh:554 #14 0x000000010007ffa0 in fl_mac_flush_and_wait () at style.hh:554 #15 0x0000000100083c6f in Fl::run () at style.hh:554
This gets us on track!
Dig...
In fltk-1.3-rc6, Fl_mac.cxx, it says:
<quote>
/** * This public function handles all events. It wait a maximum of * 'time' secods for an event. This version returns 1 if events * other than the timeout timer were processed. * * \todo there is no socket handling in this code whatsoever */ int fl_wait( double time ) { do_queued_events( time ); return (got_events); }
</quote>
so it looks like when there're sockets to watch, there's a busy wait (because it sometimes work).
This is for the FLTK devs to answer.
Interesting find. Indeed if you look at FL_wait in FL_x.cxx, they issue a select system call that can identify socket events, while the mac version seems to only be a timeout based mechanism. I just emailed Manolo Gouy from FLTK (he seems in charge of the Mac section), and I'll let you know. BTW, FL_mac.cxx seems to be deprecated, and their most recent developments is in FL_cocoa.mm.
As a wild shot I'd try:
Fl_cocoa.mm:680 - time_to_wait = 0.0; + time_to_wait = 0.2;
Or set it to always 0.1 and see what happens.
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
participants (6)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
obeythepenguin＠gmail.com -
onepoint＠starurchin.org -
rf.opensource＠gmail.com