Hello again, The attached patch fixes the problem for me, and I believe zeroing some data structures before they're used won't hurt things for anyone else.
Noah On Sat, Feb 12, 2011 at 8:45 PM, Noah Lavine <noah.b.lav...@gmail.com> wrote: > Hi all, > > I think I have isolated the error (although in fact there are two > things that should be fixed). > > I gdb'd Guile's executable and looked at the struct sockaddr just > before it was passed to bind. There were two mistakes. > > First of all, that struct has an sa_len field which is supposed to > contain its length, but in fact contained junk. Second of all, it > should have been padded with 8 bytes of zeros at the end, but it > wasn't. After experimenting a bit, it turns out that padding with > zeros was what made the difference, but probably the sa_len field > should be fixed anyway. I'll work on a patch for this. > > Noah > > On Sat, Feb 12, 2011 at 8:22 PM, Noah Lavine <noah.b.lav...@gmail.com> wrote: >> Hi, >> >>> #x49 is 73 :) >> >> If I knew a facepalm emoticon, I would use it now. :) >> >>> Could the lseek could be the problem? >> >> Maybe, but I suspect not. My man page for lseek says that lseek will >> fail with ESPIPE if it is called on a socket, and my errno.h defines >> ESPIPE to be 29, which is the error we got. So that's what's happening >> there. >> >> However, I looked to see where the lseek call was coming from, and it >> happens in scm_fdes_to_port, on line 564 of fports.c. The lseek is >> done for the purpose of checking whether the port supports lseek, and >> when it returns -1, we put an entry into some data structure (port >> table?) saying that it doesn't support random access. So it looks like >> that error is actually expected in the port code. >> >> Noah >> >
0001-libguile-socket.c-fix-use-of-uninitialized-memory.patch
Description: Binary data