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!
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? Please keep testing. Cheers, Johannes
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.-
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! :)
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
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
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 :)
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
Hi Jeremy, On Thu, Feb 04, 2010 at 06:32:29PM +0000, Jeremy Henty wrote:
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?
I'd definitely try with wrappers! -- Cheers Jorge.-
On Sun, Feb 07, 2010 at 09:10:44AM -0300, Jorge Arellano Cid wrote:
On Thu, Feb 04, 2010 at 06:32:29PM +0000, Jeremy Henty wrote:
On Wed, Feb 03, 2010 at 08:07:13AM +0000, corvid wrote:
I've been wondering whether it is possible to check dpid and the dpis as well. [...]
[...] 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?
I'd definitely try with wrappers!
I think you're right. It's a little kludgy but at least it's robust - you know for sure which program the output is from and you don't get scrambled results from multiple processes writing to the same stream. Regards, Jeremy Henty
Hello, 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.
I think we need a decision about this soon. I made a short attempt to switch DPIs back to UDS, but couldn't get it working yet. If I find some more time this weekend I will try again. I would propose that we decide on Monday, whether we release our current rc1 as it is and document the issue or go with a possible UDS solution. In both cases I want the release to happen next week. Cheers, Johannes
participants (4)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org