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.-