[Dillo-dev]dillo-0.8.3-rc1.tar.bz2
Hi there, The release of dillo-0.8.3 is very close now. Today I prepared the release candidate tarball for it. Please test and send some feedback; the last request for feedback on the CVS had a single answer. !? Get rc1 from: http://www.dillo.org/download/dillo-0.8.3-rc1.tar.bz2 It should be out in early September. -- Cheers Jorge.-
On Wed, Sep 29, 2004 at 02:37:01PM -0400, Jorge Arellano Cid wrote:
Get rc1 from:
http://www.dillo.org/download/dillo-0.8.3-rc1.tar.bz2
It should be out in early September.
Ehhrm, it should say: early October -- Cheers Jorge.-
On Wed, 29 Sep 2004 15:03:06 -0400, Jorge Arellano Cid <jcid@dillo.org> wrote:
On Wed, Sep 29, 2004 at 02:37:01PM -0400, Jorge Arellano Cid wrote:
i still didnt detect any problem, so looks fine 8)
It should be out in early September. Ehhrm, it should say: early October
time travel... 8) Thanks -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
Hi everybody, the rendering is really much better in the 0.8.3 version. Well done! Unfortunately, I'm experiencing problems with the new version that I've never had with 0.8.2: 1. Dillo displays a page without the embedded GIF image, showing the alternate text instead. It starts consuming all cpu time, but still responds to keyboard and mouse input (history navigation; no new pages are displayed). 2. Dillo doesn't display a page at all. Cpu/input behaviour as before. The problems only occur with certain local files, not http pages. Moreover, they don't occur deterministically. They seem to happen somewhat more often if one follows a link instead of loading a page from the command line. The "bad" pages are from some documentation I've written, available at http://www-fourier.ujf-grenoble.fr/~franz/convex/doc/current/ . But remember that so far the problems have only occurred with local files. You can download the complete documentation (roughly 80 kB) at http://www-fourier.ujf-grenoble.fr/~franz/convex/files/current/convex-doc.ta... (gunzip it in a new directory). Problem 1 occurs with the page "about.html" (link "About this document" on the main page "index.html"). It happens in about 50% of all cases. It does not depend on the setting of w3c_plus_heuristics in dillorc. Problem 2 ocurred so far with the pages "PFACE.html" (link: Operators and functions "for PFACE") and "GFDL.html" (link "GNU free document license"). This problem is extremely rare, though (2 or 3 times in all). Here is Dillo's command line output for a problem 1 case: ~/convex/doc/1.1$ dillo index.html dillo_dns_init: Here we go! Disabling cookies. Nav_open_url: Url=>about:splash< Nav_open_url: Url=>file:/home/franz/convex/doc/1.1/index.html< main.c:153: get_command: dpid tag is NULL : main.c:326: main: get_command failed : Dpi_parse_token: [<dpi cmd='start_send_page' url='file:/home/franz/convex/doc/1.1/index.html'>] Dpi: [Dpi_process_io] IOClose Nav_open_url: Url=>file:/home/franz/convex/doc/1.1/about.html< main.c:153: get_command: dpid tag is NULL : main.c:326: main: get_command failed : Dpi_parse_token: [<dpi cmd='start_send_page' url='file:/home/franz/convex/doc/1.1/about.html'>] Dpi: [Dpi_process_io] IOClose main.c:153: get_command: dpid tag is NULL : main.c:326: main: get_command failed : [sock_handler_write]: Broken pipe [sock_handler_write]: Broken pipe *** Here I've closed the Dillo window *** Dillo: normal exit! Sorry for reporting the bug rather late after Jorge's email, but I came across this problem only yesterday. All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse
On Wed, 6 Oct 2004 13:52:40 +0200 Matthias Franz <Matthias.Franz@ujf-grenoble.fr> wrote:
1. Dillo displays a page without the embedded GIF image, showing the alternate text instead. It starts consuming all cpu time, but still responds to keyboard and mouse input (history navigation; no new pages are displayed).
2. Dillo doesn't display a page at all. Cpu/input behaviour as before.
The problems only occur with certain local files, not http pages. Moreover, they don't occur deterministically. They seem to happen somewhat more often if one follows a link instead of loading a page from the command line. [...] But remember that so far the problems have only occurred with local files.
this is actually the brokenness of the dpi subsystem you are seeing there (file: was recently switched to be a dpi instead of native), and this behaviour occurs with all dpis (file, ftp, https, custom filter ones...) you're also lucky it "only" hangs, i see both dillo and dpid regularly crashing... - Thorben
On Wed, Oct 06, 2004 at 06:55:00PM +0200, Thorben Thuermer wrote:
On Wed, 6 Oct 2004 13:52:40 +0200 Matthias Franz <Matthias.Franz@ujf-grenoble.fr> wrote:
1. Dillo displays a page without the embedded GIF image, showing the alternate text instead. It starts consuming all cpu time, but still responds to keyboard and mouse input (history navigation; no new pages are displayed).
2. Dillo doesn't display a page at all. Cpu/input behaviour as before.
The problems only occur with certain local files, not http pages. Moreover, they don't occur deterministically. They seem to happen somewhat more often if one follows a link instead of loading a page from the command line. [...] But remember that so far the problems have only occurred with local files.
this is actually the brokenness of the dpi subsystem you are seeing there (file: was recently switched to be a dpi instead of native), and this behaviour occurs with all dpis (file, ftp, https, custom filter ones...) you're also lucky it "only" hangs, i see both dillo and dpid regularly crashing...
I'll try to look at your report today Matthias. People having troubles with the new dpi-based "file:" handling, or other dpis, by all means please report how. A way to reproduce, the best that you can provide. That way we can work on the bugs that otherwise we may remain unaware of. Like these. -- Cheers Jorge.-
Matthias, On Wed, Oct 06, 2004 at 01:52:40PM +0200, Matthias Franz wrote:
Hi everybody,
the rendering is really much better in the 0.8.3 version. Well done!
Unfortunately, I'm experiencing problems with the new version that I've never had with 0.8.2:
1. Dillo displays a page without the embedded GIF image, showing the alternate text instead. It starts consuming all cpu time, but still responds to keyboard and mouse input (history navigation; no new pages are displayed).
2. Dillo doesn't display a page at all. Cpu/input behaviour as before.
The problems only occur with certain local files, not http pages. Moreover, they don't occur deterministically. They seem to happen somewhat more often if one follows a link instead of loading a page from the command line.
The "bad" pages are from some documentation I've written, available at http://www-fourier.ujf-grenoble.fr/~franz/convex/doc/current/ . But remember that so far the problems have only occurred with local files. You can download the complete documentation (roughly 80 kB) at http://www-fourier.ujf-grenoble.fr/~franz/convex/files/current/convex-doc.ta... (gunzip it in a new directory).
Problem 1 occurs with the page "about.html" (link "About this document" on the main page "index.html"). It happens in about 50% of all cases. It does not depend on the setting of w3c_plus_heuristics in dillorc.
Problem 2 ocurred so far with the pages "PFACE.html" (link: Operators and functions "for PFACE") and "GFDL.html" (link "GNU free document license"). This problem is extremely rare, though (2 or 3 times in all).
I tried a few times with and without dpid already running and can't reproduce it on my machine. I'll keep trying to get a way or hint on it, this is just to let you know. It is very hard to try to debug a problem you don't know how to reproduce. The good news is that I found a way to crash the current file-dpi by hitting reload quickly. This didn't happen with 0.8.2, so I'll start investigating here hoping it gets me to the root of the same problem. If someone here on the mailing list can reporduce it at home, a report on how it happens or not would also be welcomed.
[...] Sorry for reporting the bug rather late after Jorge's email, but I came across this problem only yesterday.
No problem. It looks like we'll have to delay the release and make an rc2. -- Cheers Jorge.- PS: I kept waiting some patches from you. What happened? Or is it my head that lost track of them... ;-)
On Wed, Oct 06, 2004 at 01:52:40PM +0200, Matthias Franz wrote:
Hi everybody,
the rendering is really much better in the 0.8.3 version. Well done!
Unfortunately, I'm experiencing problems with the new version that I've never had with 0.8.2:
1. Dillo displays a page without the embedded GIF image, showing the alternate text instead. It starts consuming all cpu time, but still responds to keyboard and mouse input (history navigation; no new pages are displayed).
Yesterday I was able to reproduce this. Attaching gdb to the process showed that the CPU hog is produced outside Dillo's code (between gtk and glib with intermediate calls to libc). This most probably is an IO watch without its callback. Not an easy to debug sceneray, but at least a starting point. -- Cheers Jorge.-
On Wed, Oct 06, 2004 at 01:52:40PM +0200, Matthias Franz wrote:
Hi everybody,
the rendering is really much better in the 0.8.3 version. Well done!
Unfortunately, I'm experiencing problems with the new version that I've never had with 0.8.2:
1. Dillo displays a page without the embedded GIF image, showing the alternate text instead. It starts consuming all cpu time, but still responds to keyboard and mouse input (history navigation; no new pages are displayed).
2. Dillo doesn't display a page at all. Cpu/input behaviour as before.
The problems only occur with certain local files, not http pages. Moreover, they don't occur deterministically. They seem to happen somewhat more often if one follows a link instead of loading a page from the command line. [...]
Well, I've devoted several days to this BUG. It's one of the hard kind to find and fix. It has to do with race conditions due to threading and communication with external processes. Sometimes it shows, some others not. I'm very advanced on it. Porting the file dpi to a dpi server helped me to reproduce the bug (and to discard the multiple random scheduled external processes as the root of the problem). I know the exact line where it crashes, and I'm in the process of trying to understand how it gets there. Shall "the force" be with me, a bug fix may come soon! :-) -- Cheers Jorge.-
On Tue, Oct 12, 2004 at 12:49:21PM -0300, Jorge Arellano Cid wrote:
Well, I've devoted several days to this BUG.
Dear Jorge, the time and energy you have been spending on this bug shows me how much you are dedicated to high quality software. Thanks a lot! PS: Once you have a bugfix, I'd be happy to test it. -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse
On Wed, Oct 13, 2004 at 02:01:01PM +0200, Matthias Franz wrote:
On Tue, Oct 12, 2004 at 12:49:21PM -0300, Jorge Arellano Cid wrote:
Well, I've devoted several days to this BUG.
Dear Jorge,
the time and energy you have been spending on this bug shows me how much you are dedicated to high quality software.
Thanks a lot!
PS: Once you have a bugfix, I'd be happy to test it.
A patch is in the CVS! Finally I figured it out: there were two race conditions, one on closing the write end of the socket (the easy one) and another on the thin time-slice between server FD close and the IO watch for it being scheduled inside Dillo. The problem was very hard to spot as it wasn't on a variable shared explicitly among threads, but on a file descriptor. If somewhere inside the above mentioned time-slice, Dillo requested for a new FD and the kernel noticed, and decided to reuse the FD, then there were problems. I say there were problems because the data transfer had a good chance to succeed on a fascinatingly wicked way! (covering up the BUG). The patch makes changes in several places, the most interesting of them being the threads list being sorted by a primary key other than the FD (this allows handling the CCCs for both, the just closed and the just openned one). I left the thread list's debug messages for checking purposes. If you see two identical FDs in the list, that was the bug (handled now). It worked OK on all my tests for the file dpi server and also for the file dpi filter. I left the dpi server option as default because it spawns less processes. If you want to test the file filter dpi, just compile dillo and run from the command line. To test the file dpi server, do a: make install-strip and remove, or 'chmod -x', the file.filter.dpi. (usually /usr/local/lib/dillo/dpi/file/file.filter.dpi). ... and tell us how it works. -- Cheers Jorge.-
participants (4)
-
higuita -
Jorge Arellano Cid -
Matthias Franz -
Thorben Thuermer