Re: Bug in Guile's Posix Networking

[Noah Lavine]

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 <address@hidden> 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 <address@hidden> 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