guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in Guile's Posix Networking


From: Noah Lavine
Subject: Re: Bug in Guile's Posix Networking
Date: Sat, 12 Feb 2011 22:00:42 -0500

And this patch sets the sin_len member of struct sockaddr_in
correctly, even if it doesn't appear in struct sockaddr. It's not
needed to fix the previous bug, but it is more correct. Also it seems
like the sort of thing that could cause trouble later if it's not
fixed.

On Sat, Feb 12, 2011 at 9:22 PM, Noah Lavine <address@hidden> wrote:
> 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
>>>
>>
>

Attachment: 0001-configure.ac-sometimes-the-sin_len-member-appears-in.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]