- Dillo-dev - lists.mailman3.com

valgrind [Re: [Dillo-dev] dillo-2.2-rc1]

by onepoint＠starurchin.org

On Wed, Feb 03, 2010 at 08:07:13AM +0000, corvid wrote: > Jeremy wrote: > > > > Thanks. Everyone is welcome to suggest improvements. > > I've been wondering whether it is possible to check dpid and the > dpis as well. Apparently there's a --trace-children=yes option, but > it's probably not that simple :) I'll look into it. It may not be so complicated - valgrind logs the PID so it should be easy to group the log entries by process. The tricky thing is identifying the process - currently I just slurp the whole output before doing anything, by which time the dpi might have died. It might be better to process it line-by-line so I can check the process table right away. That would need a little re-engineering. Or maybe it would be better to replace the dpis with wrappers that run valgrind? Hmm, dillo is somewhat unusual in that it forks children that are intended to keep running after the parent dies. I don't know whether valgrind will handle that usefully. This needs some research. Meanwhile, you've got to love this extract from "man valgrind" regarding the "--child-silent-after-fork" option: This can make the output less confusing (although more misleading) Meaningful and correct: pick one! :-) Regards, Jeremy Henty

Feb. 4, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by bf2006a＠yahoo.com

--- On Sun, 1/31/10, Jorge Arellano Cid <jcid(a)dillo.org> wrote: ... > > > > > > Simple solution: try something like this > script to > > > start dillo: > > > > > > #!/bin/sh > > > ST="`ps -ef|grep "[0-9] dpid"|wc -l`" Since ps(1) on *BSD differs from POSIX, I used instead: ps -ax -ocomm | grep -ce "dpid" > > > if [ "$ST" = "1" ]; then > > > echo "Dpid is running OK!" > > > dillo > > > else > > > echo "Dpid is NOT running" > > > dpid & > > > dillo > > > fi > > ... > You can increase dpid's time to live: > > dpid/main.c:208 > - int dpid_idle_timeout = 60 * 60; /* > default, in seconds */ > + int dpid_idle_timeout = 60 * 60 * 24; /* > default, in seconds */ > > > Or simply let it linger forever: > > dpid/main.c:207 > - int i, n = 0, open_max; > + int i, n = 0, linger = 1, open_max; > dpid/main.c:295 > - if > (server_is_running("downloads")) > + if (linger || > server_is_running("downloads")) > > > Please test both and send your feedback. Once > we have a usable > workaround, we may think of a good patch (e.g. a dillorc > option). I have used tested both methods, and both seem to prevent the timeouts (or at least the great majority of them, in the case of the patch that just increases the ttl), when used with something like the script above. Such a script is not quite as convenient as simply starting dillo, but probably offers an adequate workaround for the initial part of this problem, for the moment. > Last but not the least, IMHO, > using verbs like "plagued" and > expressions like "or sit on my hands" doesn't help in > dillo-dev. Perhaps something is lost in translation, or we're just proving that what one person considers colorful or descriptive is considered to be too strongly worded by another. In any event, my language was not meant to be an attack upon anyone, and no one should construe it as such. On the whole, the new version looks good. Congratulations and thanks to those who put time and energy into improving dillo since the last release. b.

Feb. 4, 2010

valgrind [Re: [Dillo-dev] dillo-2.2-rc1]

by corvid＠lavabit.com

Jeremy wrote: > On Tue, Feb 02, 2010 at 11:11:05PM +0100, Johannes Hofmann wrote: > > The page http://starurchin.org/dillo/valgrind.html is really nice > > now! > > Thanks. Everyone is welcome to suggest improvements. I've been wondering whether it is possible to check dpid and the dpis as well. Apparently there's a --trace-children=yes option, but it's probably not that simple :)

Feb. 3, 2010

dillo-2.2-rc1

by onepoint＠starurchin.org

On Tue, Feb 02, 2010 at 11:11:05PM +0100, Johannes Hofmann wrote: > @Jeremy: haven't looked at your dillo valgrind logs for a while. Me neither, actually! They haven't shown anything new for a long time, which implies that the Dillo devs have been able to do a lot of work without adding new leaks. The Http_host_connection_get() leak looks like a recent regression, though. > The page http://starurchin.org/dillo/valgrind.html is really nice > now! Thanks. Everyone is welcome to suggest improvements. Regards, Jeremy Henty

Feb. 3, 2010

dillo-2.2-rc1

by Johannes.Hofmann＠gmx.de

On Tue, Feb 02, 2010 at 10:02:34PM +0000, corvid wrote: > Johannes wrote: > > Any other issues or success stories maybe? > > Jeremy's valgrind logs show some Http_host_connection_get() leakage. > should be fixed now. Thanks for pointing this out. Johannes

Feb. 3, 2010

dillo-2.2-rc1

by Johannes.Hofmann＠gmx.de

On Tue, Feb 02, 2010 at 10:02:34PM +0000, corvid wrote: > Johannes wrote: > > Any other issues or success stories maybe? > > Jeremy's valgrind logs show some Http_host_connection_get() leakage. @Jeremy: haven't looked at your dillo valgrind logs for a while. The page http://starurchin.org/dillo/valgrind.html is really nice now! I will try to fix the leak. Cheers, Johannes

Feb. 2, 2010

dillo-2.2-rc1

by corvid＠lavabit.com

Johannes wrote: > Any other issues or success stories maybe? Jeremy's valgrind logs show some Http_host_connection_get() leakage.

Feb. 2, 2010

dillo-2.2-rc1

by Johannes.Hofmann＠gmx.de

On Tue, Feb 02, 2010 at 05:16:38PM -0300, Jorge Arellano Cid wrote: > On Tue, Feb 02, 2010 at 01:11:38PM +0100, Johannes Hofmann wrote: > > On Sun, Jan 31, 2010 at 02:34:37AM +0000, corvid wrote: > > > As you may have already noticed, we're at RC1 for the next release. > > > Johannes has built a tarball: > > > > > > http://www.dillo.org/download/dillo-2.2-rc1.tar.bz2 > > > SHA1: 146216a1541b20a3e042c62c0db8ee42f173ed01 > > > > > > Please test! > > > > Ok, for now we know about the TCP blackhole issue reported by bf. > > > > Any other issues or success stories maybe? > > Fix for a compilation warning: > > diff -pru /home/jcid/C/Dillo/d2/dillo/dpid/dpidc.c dillo-2.2-rc1/dpid/dpidc.c > --- /home/jcid/C/Dillo/d2/dillo/dpid/dpidc.c 2010-01-25 11:28:59.000000000 > -0300 > +++ dillo-2.2-rc1/dpid/dpidc.c 2010-02-01 14:25:01.000000000 -0300 > @@ -98,7 +98,8 @@ int main(int argc, char *argv[]) > } else if (strcmp(argv[1], "chat") == 0) { > printf("Please enter the message: "); > bzero(buffer,256); > - fgets(buffer,255,stdin); > + if (fgets(buffer,255,stdin) == NULL) > + MSG_ERR("dpidc: Can't read the message\n"); > } else { > MSG_ERR("main: Unknown operation '%s'\n", argv[1]); > print_usage(argv[0]); Thanks, committed! :)

Feb. 2, 2010

dillo-2.2-rc1

by jcid＠dillo.org

On Tue, Feb 02, 2010 at 01:11:38PM +0100, Johannes Hofmann wrote: > On Sun, Jan 31, 2010 at 02:34:37AM +0000, corvid wrote: > > As you may have already noticed, we're at RC1 for the next release. > > Johannes has built a tarball: > > > > http://www.dillo.org/download/dillo-2.2-rc1.tar.bz2 > > SHA1: 146216a1541b20a3e042c62c0db8ee42f173ed01 > > > > Please test! > > Ok, for now we know about the TCP blackhole issue reported by bf. > > Any other issues or success stories maybe? Fix for a compilation warning: diff -pru /home/jcid/C/Dillo/d2/dillo/dpid/dpidc.c dillo-2.2-rc1/dpid/dpidc.c --- /home/jcid/C/Dillo/d2/dillo/dpid/dpidc.c 2010-01-25 11:28:59.000000000 -0300 +++ dillo-2.2-rc1/dpid/dpidc.c 2010-02-01 14:25:01.000000000 -0300 @@ -98,7 +98,8 @@ int main(int argc, char *argv[]) } else if (strcmp(argv[1], "chat") == 0) { printf("Please enter the message: "); bzero(buffer,256); - fgets(buffer,255,stdin); + if (fgets(buffer,255,stdin) == NULL) + MSG_ERR("dpidc: Can't read the message\n"); } else { MSG_ERR("main: Unknown operation '%s'\n", argv[1]); print_usage(argv[0]); Everything else seems OK so far. I'm expecting feedback from "bf". -- Cheers Jorge.-

Feb. 2, 2010

Starting dpis on FreeBSD: blackhole(4) timeouts

by Johannes.Hofmann＠gmx.de

On Sun, Jan 31, 2010 at 04:44:57PM -0300, Jorge Arellano Cid wrote: > On Sun, Jan 31, 2010 at 07:02:54PM +0000, corvid wrote: > > bf wrote: > > > Because blackhole(4) is a common security measure, and because this > > > problem did not exist under the previous dpi framework, it must be > > > considered a regression, even if, in hindsight, it is to be "expected". > > > > I finally looked back to refresh my memory on why we switched to inet > > sockets: Minix. If we do return to Unix sockets eventually, what is the > > thinking on what we would do for Minix? > > At some point in time Minix 3 will have to implement UDS. > In the meanwhile they can use the version with inet sockets. What shall we do about this TCP blackhole issue? Should we try to switch back to UDS before release? Cheers, Johannes

Feb. 2, 2010