- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] tight loop on IO error

by Phil Pennock

On 2003-09-01 at 14:38 +0200, Andreas Schweitzer wrote: > I've noticed similar behaviour a lot of times on the FreeBSD > machine here but not on my Linux box. Since I couldn't > actually pin point the exact problem I did not file a bug > report yet. This was FreeBSD too. Perhaps some different error-code elsewhere? All I did was fix the problem for me -- it's possible that there's still some object cleanup elsewhere that really needs doing ... -- 2001: Blogging invented. Promises to change the way people bore strangers with banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Sept. 1, 2003

Re: [Dillo-dev] tight loop on IO error

by Andreas Schweitzer

Hi, On Mon, Sep 01, 2003 at 11:45:06AM +0000, Phil Pennock wrote: > When viewing the page [warning, many images]: ^^^^^^^^^^^^^^^^^^^^ and incorrect HTML :-) > <URL:http://primates.ximian.com/~miguel/all.html> > dillo runs into a tight loop when there's a broken pipe error on > retrieving one of the last couple of images. I've noticed similar behaviour a lot of times on the FreeBSD machine here but not on my Linux box. Since I couldn't actually pin point the exact problem I did not file a bug report yet. Occasionally I would use gdb to see what's up and found indeed broken pipes - but not always. Also it seemed to be hard to reproduce on my Linux machine. > I've tracked down the cause; I'm running the 0.7.3 code, with Frank's > patch, but have confirmed the presence of the code in HEAD via the > WebCVS interface (wonderful thing). I noticed my lock-ups on both the current CVS version, the 0.7.3 release version and patched versions. > In IO/IO.c:IO_write(), if the write() returns (-1) then unless the error > is one of EINTR or EGAIN, the case isn't handled and the "while (1) {}" > loop runs wild. The error conditions and the error handling is probably different enough on FreeBSD vs. Linux so that I notice it more on FreeBSD. Now, that the problem is clear, here is another way to trigger the problem on FreeBSD : try to access a non-responsive web server, and eventually CVS-dillo will freeze not noticing the timeout error, with the patch it no longer freezes ! Great ! (right now you can try www.sco.com, another DOS-attack ? :-) ... and wait 1-2 minutes until the timeout kicks in and watch the unpatched dillo hang with high CPU usage) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Sept. 1, 2003

Re: [Dillo-dev] Rendering problem

by Andreas Kemnade

On Fri, 29 Aug 2003 10:31:29 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > Now, it still shows several rendering problems. If those are > because of lack of implementation of "floats" we should fix it > someday. If it's because of bad HTML, you know our policy. > > OTOH, I believe slashdot webmasters will not pose major > problems to fix their HTML if they're emailed with the facts... Please fix it (at least the double </td></tr>). > > Please investigate those and report to them. > I have saved the index page (http://slashdot.org/) and edited it a bit. I hope the error ist still in common code. I found this: This simple fix makes the page readable with dillo! --- slashdot.html Mon Sep 1 14:00:58 2003 +++ slashdot1.html Mon Sep 1 14:19:05 2003 @@ -11,8 +11,8 @@ MARGINWIDTH="0" MARGINHEIGHT="0">  -<table width="100%" border="0" cellspacing="0" cellpadding="0" bgcolor="#999999"> <FORM ACTION="http://www.osdn.com/osdnsearch.pl" METHOD="GET"> +<table width="100%" border="0" cellspacing="0" cellpadding="0" bgcolor="#999999"> <tr><td><FONT size="-1"> <a href="http://www.osdn.com" title="click to visit OSDN.com!"><B><FONT color="#006699">OSDN</FONT></B></A> @@ -55,8 +55,8 @@ <td nowrap width="20" align="right" valign="middle"><FONT size="-1"><A HREF="//slashdot.org/users.pl?op=savemiscopts&opt_osdn_navbar=0"><B>X</B></A> </FONT></td> </tr> -</FORM> </table> +</FORM>  @@ -158,7 +158,7 @@  <A HREF="//science.slashdot.org">Science</A></FONT><BR>  <font size="1"><B>4 more</B></FONT></TD></TR> <TR><TD ><FONT SIZE="2">  <A HREF="//yro.slashdot.org">YRO</A></FONT></TD></TR> -</TD></TR> + <TR><TD> </TD></TR> <TR> <TD bgcolor="#006666"><FONT color="#FFFFFF"> Help</FONT></TD> Greetings Andreas Kemnade

Sept. 1, 2003

tight loop on IO error

by Phil Pennock

When viewing the page [warning, many images]: <URL:http://primates.ximian.com/~miguel/all.html> dillo runs into a tight loop when there's a broken pipe error on retrieving one of the last couple of images. I've tracked down the cause; I'm running the 0.7.3 code, with Frank's patch, but have confirmed the presence of the code in HEAD via the WebCVS interface (wonderful thing). In IO/IO.c:IO_write(), if the write() returns (-1) then unless the error is one of EINTR or EGAIN, the case isn't handled and the "while (1) {}" loop runs wild. With a quick change (including new debug statement) I now see: IO_callback: [GIOcond 4] IO_write IO_write: Broken pipe [errno 32] [St -1] IO_write: aborting: Broken pipe [errno 32] The patch includes some extra cosmetic DEBUG changes which can be safely discarded (and the DEBUG_LEVEL change probably should be ...) -----------------------------< cut here >------------------------------- --- /home/pdp/tmp/zshmiVuTI Mon Sep 1 13:43:24 2003 +++ IO.c Mon Sep 1 13:42:58 2003 @@ -30,7 +30,7 @@ #include "../klist.h" #include "IO.h" -#define DEBUG_LEVEL 5 +#define DEBUG_LEVEL 1 #include "../debug.h" @@ -399,8 +399,12 @@ St = read(io->FD, io->Buf, io->BufSize); io->Status = St; - DEBUG_MSG(3, " IO_read: %s [errno %d] [St %d]\n", - g_strerror(errno), errno, St); + if (errno) { + DEBUG_MSG(3, " IO_read: %s [errno %d] [St %d]\n", + g_strerror(errno), errno, St); + } else { + DEBUG_MSG(3, " IO_read: [St %d] success\n", St); + } if ( St < 0 ) { /* Error */ @@ -446,18 +450,27 @@ St = write(io->FD, io->Buf, io->BufSize); io->Status = St; - DEBUG_MSG(3, " IO_write: %s [errno %d] [St %d]\n", - g_strerror(errno), errno, St); + if (errno) { + DEBUG_MSG(3, " IO_write: %s [errno %d] [St %d]\n", + g_strerror(errno), errno, St); + } else { + DEBUG_MSG(3, " IO_write: success [St %d]\n", St); + } if ( St < 0 ) { /* Error */ io->Status = -errno; - if (errno == EINTR) { + switch (errno) { + case EINTR: continue; - } else if (errno == EAGAIN) { + case EAGAIN: DEBUG_MSG(4, " IO_write: EAGAIN\n"); ret = TRUE; break; + default: + DEBUG_MSG(5, " IO_write: aborting: %s [errno %d]\n", + g_strerror(errno), errno); + return FALSE; } } else if ( St < io->BufSize ){ /* Not all data written */

Sept. 1, 2003

path for support chinese

by super_hoo

I knowed that it had a patch for dillo0.7.2 to supportting Chinese. Where could I find this patch ? thanks a lot. ______________________________________ =================================================================== µ±µ±ÍøÈ«³¡ÒôÏñ5ÕÛ·â¶¥£¬ÓÅ»ÝŒŽœ«œáÊø£¡ (http://ad4.sina.com.cn/sina/dangdang0825.html)

Sept. 1, 2003

Re: [Dillo-dev] Rendering problem (temp-solution.. no patch)

by Ralph Slooten

It seems slashdot.org has serious issues with it's code, so bad that it makes it impossible, hard, or just a PITA to view with Dillo. Instead of patching dillo to render these pages despite obvious errors, I did a bit of simple PHP coding to do the following: I wrote a small php script to download a current working version of slashdot using a Mozilla cookie, wget, tidy and sed. It seems to work fine now with dillo, but probably will skrew up from time to time if 2 users at exactly the same time try refresh the page (I can't be bothered to make this into a full-blown project). It's only ment as a temp solution, and also _only_ supports the main page, linking goes directly to /.'s site, where the rendering is messed up again. http://axljab.homelinux.org:8080/slashdot/ Yeah, this is only for you /. junkies that love using Dillo, and although my internet connection may not be the best in the world, who knows, it may even work for you ;-) Also the page I created will not parse the page like in your own cookies, but is simply the default page using a cokkie of my own, but heck, it's the main page that's most interesting isn't it. Another note, each time the page is refreshed, the php downloads a new copy of/. .... so please don't abuse by continuously refreshing as it will kill my bandwidth, and possibly get me banned from slashdot altogether. Enjoy, and let me know if it works for you ... I love success stories ;-) Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Aug. 31, 2003

Re: [Dillo-dev] Rendering problem

by Madis Janson

On Fri, 29 Aug 2003, Jorge Arellano Cid wrote: > On Thu, 28 Aug 2003, Ralph Slooten wrote: > > > On Thu, 28 Aug 2003 12:57:36 -0400 (EDT) > > "Andrew A. Gill" <superluser(a)frontiernet.net> wrote: > > > > > Normally, this isn't something that I really care about, but now it's > > > causing slashdot to be rendered as black-on-black text, thus depriving me > > > of my ability to read about the new MD5 sums that the RIAA is using. > > > > Yes, I'm getting this too since today. It's probably a small html error > > somewhere, but it's totally skrewed up dillo's rendering to the fullest here. > > Unfortunately slashdot is sending awful HTML-like content. > > The black text can be explained because they explicitly set the > background, textcolor and visited links to black! (<BODY ...>). > > Probably it changes with CSS. > No, slashdot does not use CSS. The white background is created by tables and is still visible, but articles now seem to be on the side of it, not on it (talking about main page). Probably some table/tr tags are in wrong order and screw up the push/pop parsing. Reason why i think so is that the slashdot page can be seen quite ok in dillo with this patch: @@ -1139,6 +1146,8 @@ static void Html_pop_tag(DilloHtml *html Html_eventually_pop_dw(html); return; } + if (Html_match_tag(html->stack[tag_index].tag, "table>", 6)) + break; } /* Not found, just ignore. */ } But yes, its a workaround for buggy html (not invented for slashdot) and a fact that it helps just quite proves that the slashdot page has problems with tables (along other bad html). I tried to find the problem from slashdot index page, but it was such a bloody mess that my sleepy brain could not parse it at all...

Aug. 31, 2003

Re: [Dillo-dev] Rendering problem

by Ralph Slooten

On Sat, 30 Aug 2003 13:47:13 +0200 Ralph Slooten <ralph(a)genesys.ro> wrote: > After running the saved page through tidy, it actualy renders, and renders > well! Umm, just discovered that this only works for me when logged in. If I move my cookies somewhere else, re-open slashdot with dillo, save that page and try with tidy, it fails... Just thought I would let you all know before you go blue in the face trying ;-) Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Aug. 30, 2003

Re: [Dillo-dev] Rendering problem

by Ralph Slooten

On Fri, 29 Aug 2003 10:31:29 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > Try with "force_my_colors=YES". Yes, this works, althought the rendering is totally shit ;-) ... definitly not a dillo problem in this case. The problem with Slashdot is that there are just so many tables / blocks that it makes it almost impossible to locate the precise bug (although if I am correct the page is filled with bugs). > Now, it still shows several rendering problems. If those are > because of lack of implementation of "floats" we should fix it > someday. If it's because of bad HTML, you know our policy. Yes, Dillo's policy is good... if the html is wrong then that's too bad. BUT... but but but, instead of manually running through all the code, I tried it with "tidy", which found a grand total of 254 warnings and 0 errors... Well, as for 0 errors, I would say 254 warnings should be more than enough to validate one big error ;-) After running the saved page through tidy, it actualy renders, and renders well! > OTOH, I believe slashdot webmasters will not pose major > problems to fix their HTML if they're emailed with the facts... > > Please investigate those and report to them. Yes, I have reported a bug about bad HTML on the sourceforge site. It's not really a matter of bad HTML, as the HTML seems resonable, but they are using terms and codes which are definitely not HTML compliant I would say. If you are interested in the output I have put up the origional page with the "fixed" version, and output of warnings / errors here: http://members.rott.chello.nl/r.slooten2/dillo/ You will see here that it appears as if I'm still logged in.. for some reason I cannot log out, LOL .. but that's not the issue.. you can just see how many invalid html commands they seem to be using, and that after the removal of this, and the insertion of several <font> and </font> attributes fixes the whole page which then renders perfectly in Dillo. Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Aug. 30, 2003

Re: [Dillo-dev] Problems with tab patch

by Nigel Wilkinson

Thanks Frank Nigel

Aug. 29, 2003