* Bug in Guile's Posix Networking
@ 2011-02-07 6:28 Noah Lavine
2011-02-07 23:49 ` Andreas Rottmann
2011-02-12 11:26 ` Andy Wingo
0 siblings, 2 replies; 23+ messages in thread
From: Noah Lavine @ 2011-02-07 6:28 UTC (permalink / raw)
To: guile-devel
Hello all,
I think there's a bug in Guile's Posix networking capabilities. I
first noticed it a few days ago when I couldn't get the example web
server to work on my system (Mac OS X 10.6). I was getting an error
from the bind command saying "can't assign requested address". I
assumed it was a system configuration problem until I discovered that
an equivalent Python program could bind a socket without trouble.
The full story is at
http://serverfault.com/questions/231941/why-cant-i-bind-to-127-0-0-1-on-mac-os-x
(I know the Python program listed is not quite identical to the Scheme
one, but I tried it with an actually identical Scheme program and
still got the same error.) Interestingly enough, I was able to bind a
socket in Guile if I specified INADDR_ANY as its address instead of
127.0.0.1.
I hope to work on this soon, but I thought I'd ask on this list if
anyone has an idea what might be causing this.
Thanks,
Noah
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-07 6:28 Bug in Guile's Posix Networking Noah Lavine
@ 2011-02-07 23:49 ` Andreas Rottmann
2011-02-12 20:47 ` Noah Lavine
2011-02-12 11:26 ` Andy Wingo
1 sibling, 1 reply; 23+ messages in thread
From: Andreas Rottmann @ 2011-02-07 23:49 UTC (permalink / raw)
To: Noah Lavine; +Cc: guile-devel
Noah Lavine <noah.b.lavine@gmail.com> writes:
> Hello all,
>
> I think there's a bug in Guile's Posix networking capabilities. I
> first noticed it a few days ago when I couldn't get the example web
> server to work on my system (Mac OS X 10.6). I was getting an error
> from the bind command saying "can't assign requested address". I
> assumed it was a system configuration problem until I discovered that
> an equivalent Python program could bind a socket without trouble.
>
> The full story is at
> http://serverfault.com/questions/231941/why-cant-i-bind-to-127-0-0-1-on-mac-os-x
> (I know the Python program listed is not quite identical to the Scheme
> one, but I tried it with an actually identical Scheme program and
> still got the same error.) Interestingly enough, I was able to bind a
> socket in Guile if I specified INADDR_ANY as its address instead of
> 127.0.0.1.
>
> I hope to work on this soon, but I thought I'd ask on this list if
> anyone has an idea what might be causing this.
>
It would be interesting to see the output of a strace-like tool on both
the working Python program and the equivalent failing Guile program.
Apparently (according to the Interwebs), on OS X this tool is called
"dtruss".
Regards, Rotty
--
Andreas Rottmann -- <http://rotty.yi.org/>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-07 6:28 Bug in Guile's Posix Networking Noah Lavine
2011-02-07 23:49 ` Andreas Rottmann
@ 2011-02-12 11:26 ` Andy Wingo
2011-02-12 20:33 ` Noah Lavine
1 sibling, 1 reply; 23+ messages in thread
From: Andy Wingo @ 2011-02-12 11:26 UTC (permalink / raw)
To: Noah Lavine; +Cc: guile-devel
On Mon 07 Feb 2011 07:28, Noah Lavine <noah.b.lavine@gmail.com> writes:
> I think there's a bug in Guile's Posix networking capabilities. I
> first noticed it a few days ago when I couldn't get the example web
> server to work on my system (Mac OS X 10.6). I was getting an error
> from the bind command saying "can't assign requested address". I
> assumed it was a system configuration problem until I discovered that
> an equivalent Python program could bind a socket without trouble.
Does guile --listen work? It appears to use a slightly different way to
set up the sockaddr.
I was able to reproduce this bug on a machine at work, but didn't have
time to figure out what was the deal.
Also, can you file a bug in the tracker for this?
Thanks,
Andy
--
http://wingolog.org/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-12 11:26 ` Andy Wingo
@ 2011-02-12 20:33 ` Noah Lavine
2011-02-12 20:59 ` Andy Wingo
0 siblings, 1 reply; 23+ messages in thread
From: Noah Lavine @ 2011-02-12 20:33 UTC (permalink / raw)
To: Andy Wingo; +Cc: guile-devel
Hello,
> Does guile --listen work? It appears to use a slightly different way to
> set up the sockaddr.
Oddly enough, it worked the first time I tried it (at least enough to
get to a REPL - I didn't try to netcat over to it), but failed the
second and third times.
> Also, can you file a bug in the tracker for this?
I will do this right now.
Noah
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-07 23:49 ` Andreas Rottmann
@ 2011-02-12 20:47 ` Noah Lavine
2011-02-12 21:02 ` Andy Wingo
0 siblings, 1 reply; 23+ messages in thread
From: Noah Lavine @ 2011-02-12 20:47 UTC (permalink / raw)
To: Andreas Rottmann; +Cc: guile-devel
Hello,
> It would be interesting to see the output of a strace-like tool on both
> the working Python program and the equivalent failing Guile program.
> Apparently (according to the Interwebs), on OS X this tool is called
> "dtruss".
Sorry for the delay in replying. I got the output of dtruss easily
enough, but I don't know how to interpret it, and a lot of it seems to
be noise from initialization. I was hoping to learn how to interpret
it, but had no luck so far, so here is Guile's dtruss output. I can
send Python's output too if you would like, but it's similarly long:
SYSCALL(args) = return
getpid(0x7FFF5FBFF870, 0x7FFFFFE00050, 0x0) = 85226 0
open_nocancel("/dev/urandom\0", 0x0, 0x0) = 3 0
read_nocancel(0x3,
"Y=\337\353\244[\375\214!\370\261\317%\224\"2n[\306Mz\221-|\353\235?\200y\334R|\260\322\363U\236\237Im\025e\030\217\316\264=!\343\256o\024\346gm\232>\346\246\255\305\330*.!\211\215\277\316\370V\246R\273NNZ\235\032\215\342\320\200\330Q\211\344S^\210\201\027\036\306}\307\213\261\307\352\344\350\f+\332\344\003\354\0",
0x6C) = 108 0
close_nocancel(0x3) = 0 0
issetugid(0x100000000, 0x7FFF5FBFFB45, 0x7FFF5FC40530) = 0 0
geteuid(0x100000000, 0x7FFF5FBFFB45, 0x0) = 0 0
__sysctl(0x7FFF5FBFD760, 0x2, 0x7FFF5FBFD720) = 0 0
__sysctl(0x7FFF5FBFD720, 0x2, 0x7FFF5FBFD7BC) = 0 0
shared_region_check_np(0x7FFF5FBFD928, 0x0, 0x7FFF5FC1DC86) = 0 0
stat64("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x7FFF5FBFCD30,
0x7FFF5FBFD370 = 0 0
pread(0x3, "\312\376\272\276\0", 0x1000, 0x0) = 4096 0
pread(0x3, "\317\372\355\376\a\0", 0x1000, 0x1000) = 4096 0
mmap(0x1000B6000, 0x2000, 0x5, 0x12, 0x3, 0x100000000) = 0xB6000 0
mmap(0x1000B8000, 0x1000, 0x3, 0x12, 0x3, 0x100000000) = 0xB8000 0
mmap(0x1000B9000, 0x1F10, 0x1, 0x12, 0x3, 0x100000000) = 0xB9000 0
close(0x3) = 0 0
stat64("/usr/lib/libncurses.5.4.dylib\0", 0x7FFF5FBFCAB0, 0x7FFF5FBFD0F0) = 0 0
stat64("/usr/lib/libiconv.2.dylib\0", 0x7FFF5FBFCAB0, 0x7FFF5FBFD0F0) = 0 0
stat64("/usr/lib/libSystem.B.dylib\0", 0x7FFF5FBFCAB0, 0x7FFF5FBFD0F0) = 0 0
stat64("/usr/lib/system/libmathCommon.A.dylib\0", 0x7FFF5FBFC810,
0x7FFF5FBFCE50) = 0 0
madvise(0x7FFF8961F000, 0x2000, 0x5) = 0 0
open("/dev/dtracehelper\0", 0x2, 0x7FFF5FC45338) = 3 0
ioctl(0x3, 0x80086804, 0x7FFF5FBFD6C0) = 0 0
close(0x3) = 0 0
stat64("/usr/lib/libstdc++.6.dylib\0", 0x7FFF5FBFCAD0, 0x7FFF5FBFD110) = 0 0
open("/dev/dtracehelper\0", 0x2, 0x7FFF5FC45400) = 3 0
ioctl(0x3, 0x80086804, 0x7FFF5FBFD6C0) = 0 0
close(0x3) = 0 0
__sysctl(0x7FFF5FBFD5B0, 0x2, 0x7FFF5FBFD5A0) = 0 0
bsdthread_register(0x7FFF837BC3DC, 0x7FFF8379CFF8, 0x2000) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF8A0) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF890, 0x0) = 0 0
open("/dev/tty\0", 0x6, 0x1) = 3 0
close(0x3) = 0 0
getrlimit(0x1008, 0x7FFF5FBFF220, 0x7FFF8378684C) = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_COLLATE\0", 0x0, 0x1B6) = 3 0
fstat64(0x3, 0x7FFF5FBFF1F0, 0x7FFF5FBFF2BC) = 0 0
mmap(0x0, 0x1000000, 0x3, 0x1002, 0x2000000, 0x0) = 0x400000 0
munmap(0x100400000, 0x400000) = 0 0
munmap(0x101000000, 0x400000) = 0 0
read_nocancel(0x3, "1.1A\n\0", 0x1000) = 2086 0
close_nocancel(0x3) = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_CTYPE\0", 0x0, 0x1B6) = 3 0
fstat64(0x3, 0x7FFF5FBFF2D0, 0x0) = 0 0
fstat64(0x3, 0x7FFF5FBFF0B0, 0x7FFF5FBFF17C) = 0 0
lseek(0x3, 0x0, 0x1) = 0 0
lseek(0x3, 0x0, 0x0) = 0 0
read_nocancel(0x3, "RuneMagAUTF-8\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "@\004\211\0", 0xDB70) = 56176 0
close_nocancel(0x3) = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_MONETARY\0", 0x0,
0x7FFF5FBFF39A) = 3 0
fstat64(0x3, 0x7FFF5FBFF2E0, 0x0) = 0 0
read_nocancel(0x3, "USD
\n$\n.\n,\n3;3\n\n-\n2\n2\n1\n0\n1\n0\n1\n1\n\b\0", 0x22) = 34 0
close_nocancel(0x3) = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_NUMERIC\0", 0x0,
0x7FFF5FBFF3A9 = 3 0
fstat64(0x3, 0x7FFF5FBFF2F0, 0x0) = 0 0
read_nocancel(0x3, ".\n,\n3;3\n@$\b\0", 0x8) = 8 0
close_nocancel(0x3) = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_TIME\0", 0x0,
0x7FFF5FBFF3A6) = 3 0
fstat64(0x3, 0x7FFF5FBFF2F0, 0x0) = 0 0
read_nocancel(0x3,
"Jan\nFeb\nMar\nApr\nMay\nJun\nJul\nAug\nSep\nOct\nNov\nDec\nJanuary\nFebruary\nMarch\nApril\nMay\nJune\nJuly\nAugust\nSeptember\nOctober\nNovember\nDecember\nSun\nMon\nTue\nWed\nThu\nFri\nSat\nSunday\nMonday\nTuesday\nWednesday\nThursday\nFriday\nSaturday\n%H:%M:%S\n%m/%d/%Y\n%a
%b %e %X %Y\nAM\nP", 0x179) = 377 0
close_nocancel(0x3) = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/LC_MESSAGES\0",
0x0, 0x7FFF5FBFF3B6) = 3 0
fstat64(0x3, 0x7FFF5FBFF2F0, 0x0) = 0 0
read_nocancel(0x3, "^[yYsS].*\n^[nN].*\n(\0", 0x12) = 18 0
close_nocancel(0x3) = 0 0
getuid(0x1001005E5, 0x100071063, 0x0) = 0 0
getgid(0x0, 0x100071063, 0x0) = 0 0
geteuid(0x0, 0x100071063, 0x0) = 0 0
getegid(0x0, 0x100071063, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF8A0) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF890, 0x0) = 0 0
fstat64(0x2, 0x7FFF5FBFF7A0, 0x7FFF5FBFF87C) = 0 0
fstat64(0x1, 0x7FFF5FBFF7A0, 0x7FFF5FBFF87C) = 0 0
sigaction(0x14, 0x7FFF5FBFF840, 0x7FFF5FBFF870) = 0 0
sigaction(0x14, 0x7FFF5FBFF840, 0x7FFF5FBFF870) = 0 0
sigaction(0x2, 0x7FFF5FBFF840, 0x7FFF5FBFF870) = 0 0
sigaction(0x2, 0x7FFF5FBFF840, 0x7FFF5FBFF870) = 0 0
sigaction(0x3, 0x7FFF5FBFF840, 0x7FFF5FBFF870) = 0 0
sigaction(0x3, 0x7FFF5FBFF840, 0x7FFF5FBFF870) = 0 0
sigprocmask(0x1, 0x0, 0x1000A69F8) = 0x0 0
sigaction(0x3, 0x7FFF5FBFF7F0, 0x7FFF5FBFF880) = 0 0
__sysctl(0x7FFF5FBFF770, 0x2, 0x7FFF5FBFF780) = 0 0
stat64("/Users/noah/Desktop/guile/guile\0", 0x7FFF5FBFF750, 0x0) = 0 0
stat64(".\0", 0x7FFF5FBFF6C0, 0x0) = 0 0
getppid(0x1000BC000, 0x100100000, 0xFC080) = 85225 0
getpgrp(0x0, 0x100102F1, 0x0) = 85223 0
sigaction(0x14, 0x7FFF5FBFF830, 0x7FFF5FBFF860) = 0 0
getrlimit(0x1007, 0x7FFF5FBFF820, 0x7FFF8378684C) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF8A0) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF890, 0x0) = 0 0
open("meta/guile\0", 0x0, 0x0) = 3 0
ioctl(0x3, 0x4004667A, 0x7FFF5FBFF71C) = -1 Err#25
ioctl(0x3, 0x40487413, 0x7FFF5FBFF720) = -1 Err#25
lseek(0x3, 0x0, 0x1) = 0 0
read(0x3, "#!/bin/sh\n\n#\tCopyright (C) 2002, 2006, 2008, 2009 Free
Software Foundation\n#\n# @\004\b\0", 0x50) = 80 0
lseek(0x3, 0x0, 0x0) = 0 0
getdtablesize(0x3, 0x0, 0xFFFFFFFF) = 256 0
dup2(0x3, 0xFF, 0x100) = 255 0
close(0x3) = 0 0
fcntl(0xFF, 0x2, 0x1) = 0 0
fcntl(0xFF, 0x3, 0x0) = 0 0
fstat64(0xFF, 0x7FFF5FBFF7D0, 0x0) = 0 0
lseek(0xFF, 0x0, 0x1) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
read(0xFF, "#!/bin/sh\n\n#\tCopyright (C) 2002, 2006, 2008, 2009 Free
Software Foundation\n#\n# This file is part of GUILE.\n#\n# GUILE
is free software; you can redistribute it and/or modify it\n# under
the terms of the GNU Lesser General Public License as\n# publishe",
0x6C8) = 1736 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF860) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF850, 0x0) = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF570) = 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF560, 0x0) = 0 0
sigprocmask(0x3, 0x7FFF5FBFF570, 0x0) = 0x0 0
sigreturn(0x0, 0x80000000, 0x0) = 0 0
sigaction(0x2, 0x7FFF5FBFF4E0, 0x7FFF5FBFF510) = 0 0
sigaction(0x3, 0x7FFF5FBFF4E0, 0x7FFF5FBFF510) = 0 0
sigaction(0x14, 0x7FFF5FBFF4E0, 0x7FFF5FBFF510) = 0 0
open("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x0, 0x0) = 3 0
thread_selfid(0x7FFF837BC3DC, 0x7FFF8379CFF8, 0x0) = 237399 0
open_nocancel("/dev/urandom\0", 0x0, 0x7FFF7082EBE0) = 3 0
read_nocancel(0x3,
"b\224\f\221\224]\355\a\255.\302\307\301\341\253S\bBp\271.\355<B\003$j\023\223t,-[\246]\016\017b\261mT+\225/(\220dK\370\345X\017\005\017\325\342\236\032\022\254\261\031\275\371\0",
0x40) = 64 0
close_nocancel(0x3) = 0 0
mmap(0x0, 0x3000, 0x3, 0x1002, 0x1000000, 0x7FFF00000001) = 0xBB000 0
__sysctl(0x7FFF5FBFD430, 0x2, 0x7FFF5FBFD3F0) = 0 0
__sysctl(0x7FFF5FBFD3F0, 0x2, 0x7FFF5FBFD488) = 0 0
getpid(0x7FFF5FBFD380, 0x7FFFFFE00050, 0x0) = 85226 0
open_nocancel("/dev/urandom\0", 0x0, 0x0) = 3 0
read_nocancel(0x3,
"\303\256\006UB!\260\030\020\237\333\320\365\341\342z\301\354\273\347\232\271>\357/\321\362\350\3247`y\322\355\274\271\005P\0058|pyA\226*\t\r\023\2777xI\366%\350\343\302\367ed\266\325\t\323\022\377\006b\302\003\230dm\222Z\016\377\345\251\246v\304\363+a%\033q\246B\205\363\361\373h_\245\236\224\356:X-\t\271\357\213\0",
0x6C) = 108 0
close_nocancel(0x3) = 0 0
__sysctl(0x7FFF5FBFD430, 0x2, 0x7FFF5FBFD45C) = 0 0
mmap(0x0, 0x17000, 0x3, 0x1002, 0x1000000, 0x100000000) = 0xBE000 0
mmap(0x0, 0x17000, 0x3, 0x1002, 0x1000000, 0x100000000) = 0xD5000 0
mmap(0x0, 0x1000, 0x3, 0x1002, 0x1000000, 0x100000000) = 0xEC000 0
mmap(0x0, 0x200000, 0x3, 0x1002, 0x7000000, 0x100000000) = 0xED000 0
munmap(0x1000ED000, 0x13000) = 0 0
munmap(0x100200000, 0xED000) = 0 0
__sysctl(0x7FFF5FBFD590, 0x2, 0x7FFF5FBFD550) = 0 0
__sysctl(0x7FFF5FBFD550, 0x2, 0x7FFF7083B760) = 0 0
__sysctl(0x7FFF5FBFD590, 0x2, 0x7FFF5FBFD550) = 0 0
__sysctl(0x7FFF5FBFD550, 0x2, 0x7FFF7083B764) = 0 0
__sysctl(0x7FFF5FBFD590, 0x2, 0x7FFF5FBFD550) = 0 0
__sysctl(0x7FFF5FBFD550, 0x2, 0x7FFF7083B768) = 0 0
mmap(0x0, 0x3000, 0x3, 0x1002, 0x1000000, 0x100000000) = 0xED000 0
__sysctl(0x7FFF5FBFD560, 0x2, 0x7FFF5FBFD520) = 0 0
__sysctl(0x7FFF5FBFD520, 0x2, 0x7FFF5FBFD5B8) = 0 0
__sysctl(0x7FFF5FBFD560, 0x2, 0x7FFF5FBFD58C) = 0 0
mmap(0x0, 0x17000, 0x3, 0x1002, 0x1000000, 0x100000000) = 0x200000 0
mmap(0x0, 0x17000, 0x3, 0x1002, 0x1000000, 0x100000000) = 0x217000 0
mmap(0x0, 0x200000, 0x3, 0x1002, 0x7000000, 0x100000000) = 0x22E000 0
munmap(0x10022E000, 0xD2000) = 0 0
munmap(0x100400000, 0x2E000) = 0 0
Thanks a lot for showing me dtruss/strace!
Noah
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-12 20:33 ` Noah Lavine
@ 2011-02-12 20:59 ` Andy Wingo
2011-02-12 21:00 ` Noah Lavine
0 siblings, 1 reply; 23+ messages in thread
From: Andy Wingo @ 2011-02-12 20:59 UTC (permalink / raw)
To: Noah Lavine; +Cc: guile-devel
On Sat 12 Feb 2011 21:33, Noah Lavine <noah.b.lavine@gmail.com> writes:
>> Does guile --listen work? It appears to use a slightly different way to
>> set up the sockaddr.
>
> Oddly enough, it worked the first time I tried it (at least enough to
> get to a REPL - I didn't try to netcat over to it), but failed the
> second and third times.
Would that be an SO_REUSEADDR-related issue?
Musing,
Andy
--
http://wingolog.org/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-12 20:59 ` Andy Wingo
@ 2011-02-12 21:00 ` Noah Lavine
0 siblings, 0 replies; 23+ messages in thread
From: Noah Lavine @ 2011-02-12 21:00 UTC (permalink / raw)
To: Andy Wingo; +Cc: guile-devel
I tried the test program
(define addr (inet-aton "127.0.0.1"))
(define sockaddr (make-socket-address AF_INET addr 8080))
(define sock (socket PF_INET SOCK_STREAM 0))
(setsockopt sock SOL_SOCKET SO_REUSEADDR 1)
(bind sock sockaddr)
And got the same error. I also tried changing the port to 9000 and it
still happened.
Noah
On Sat, Feb 12, 2011 at 3:59 PM, Andy Wingo <wingo@pobox.com> wrote:
> On Sat 12 Feb 2011 21:33, Noah Lavine <noah.b.lavine@gmail.com> writes:
>
>>> Does guile --listen work? It appears to use a slightly different way to
>>> set up the sockaddr.
>>
>> Oddly enough, it worked the first time I tried it (at least enough to
>> get to a REPL - I didn't try to netcat over to it), but failed the
>> second and third times.
>
> Would that be an SO_REUSEADDR-related issue?
>
> Musing,
>
> Andy
> --
> http://wingolog.org/
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-12 20:47 ` Noah Lavine
@ 2011-02-12 21:02 ` Andy Wingo
2011-02-12 21:35 ` Noah Lavine
0 siblings, 1 reply; 23+ messages in thread
From: Andy Wingo @ 2011-02-12 21:02 UTC (permalink / raw)
To: Noah Lavine; +Cc: guile-devel
On Sat 12 Feb 2011 21:47, Noah Lavine <noah.b.lavine@gmail.com> writes:
>> It would be interesting to see the output of a strace-like tool on both
>> the working Python program and the equivalent failing Guile program.
>> Apparently (according to the Interwebs), on OS X this tool is called
>> "dtruss".
>
> Sorry for the delay in replying. I got the output of dtruss easily
> enough, but I don't know how to interpret it, and a lot of it seems to
> be noise from initialization.
I think that's just tracing the shell wrapper; use meta/uninstalled-env
libtool --mode=execute dtruss guile to get a more proper trace.
Anyway, what if you set the SO_REUSEADDR option?
Andy
--
http://wingolog.org/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-12 21:02 ` Andy Wingo
@ 2011-02-12 21:35 ` Noah Lavine
2011-02-12 22:00 ` Andy Wingo
0 siblings, 1 reply; 23+ messages in thread
From: Noah Lavine @ 2011-02-12 21:35 UTC (permalink / raw)
To: Andy Wingo; +Cc: guile-devel
Hello,
> I think that's just tracing the shell wrapper; use meta/uninstalled-env
> libtool --mode=execute dtruss guile to get a more proper trace.
Got it, thanks! Again there's a lot of output, but the most important
bit seems to be here (with some context):
;; Here Guile is finishing loading its compiler
open("/Users/noah/Desktop/guile/guile/module/language/assembly/spec.go\0",
0x0, 0x0) = 54 0
fstat64(0x36, 0x7FFF5FBFEC00, 0x7FFF70825630) = 0 0
mmap(0x0, 0x3D2, 0x1, 0x1, 0x36, 0x100000001) = 0xFE0000 0
stat64("/Users/noah/Desktop/guile/guile/module/language/assembly/decompile-bytecode.scm\0",
0x7FFF5FBFEA30, 0x10070A11B) = 0 0
mmap(0x0, 0x19F, 0x1, 0x1, 0x1C, 0x1FFFFFFFF) = 0x1F11000 0
;; At this point it's running the script
socket(0x2, 0x1, 0x0) = 73 0 ; make a socket -
INET family, SOCK_STREAM, internet protocol; we got one with
descriptor 73
fcntl(0x49, 0x3, 0x0) = 2 0 ; get flags for
file descriptor 49. result 2 probably means it is read and writable.
lseek(0x49, 0x0, 0x1) = -1 Err#29 ; errno 29 is "illegal seek"
setsockopt(0x49, 0xFFFF, 0x4) = 0 0 ; setsockopt on descriptor 49
bind(0x49, 0x100709EE0, 0x10) = -1 Err#49 ; bind descriptor 49.
errno 49 is "protocol driver not attached"
;; And now there's already been an error, and we'll backtrace it.
write(0x2, "Backtrace:\n\0", 0xB) = 11 0
...
It seems to me that the strangest issue is that socket() return file
descriptor 73, but the script then did system calls on file descriptor
49. Does anyone know a reason that would happen?
Noah
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-12 21:35 ` Noah Lavine
@ 2011-02-12 22:00 ` Andy Wingo
2011-02-13 1:22 ` Noah Lavine
0 siblings, 1 reply; 23+ messages in thread
From: Andy Wingo @ 2011-02-12 22:00 UTC (permalink / raw)
To: Noah Lavine; +Cc: guile-devel
Hi Noah,
On Sat 12 Feb 2011 22:35, Noah Lavine <noah.b.lavine@gmail.com> writes:
> socket(0x2, 0x1, 0x0) = 73 0 ; make a socket -
> INET family, SOCK_STREAM, internet protocol; we got one with
> descriptor 73
> fcntl(0x49, 0x3, 0x0) = 2 0 ; get flags for
> file descriptor 49. result 2 probably means it is read and writable.
> lseek(0x49, 0x0, 0x1) = -1 Err#29 ; errno 29 is "illegal seek"
> setsockopt(0x49, 0xFFFF, 0x4) = 0 0 ; setsockopt on descriptor 49
> bind(0x49, 0x100709EE0, 0x10) = -1 Err#49 ; bind descriptor 49.
> errno 49 is "protocol driver not attached"
>
> ;; And now there's already been an error, and we'll backtrace it.
> write(0x2, "Backtrace:\n\0", 0xB) = 11 0
> ...
>
> It seems to me that the strangest issue is that socket() return file
> descriptor 73, but the script then did system calls on file descriptor
> 49. Does anyone know a reason that would happen?
#x49 is 73 :)
Could the lseek could be the problem?
A
--
http://wingolog.org/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-12 22:00 ` Andy Wingo
@ 2011-02-13 1:22 ` Noah Lavine
2011-02-13 1:45 ` Noah Lavine
0 siblings, 1 reply; 23+ messages in thread
From: Noah Lavine @ 2011-02-13 1:22 UTC (permalink / raw)
To: Andy Wingo; +Cc: guile-devel
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 1:22 ` Noah Lavine
@ 2011-02-13 1:45 ` Noah Lavine
2011-02-13 2:22 ` Noah Lavine
0 siblings, 1 reply; 23+ messages in thread
From: Noah Lavine @ 2011-02-13 1:45 UTC (permalink / raw)
To: Andy Wingo; +Cc: guile-devel
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.lavine@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
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 1:45 ` Noah Lavine
@ 2011-02-13 2:22 ` Noah Lavine
2011-02-13 3:00 ` Noah Lavine
2011-02-13 20:04 ` Andy Wingo
0 siblings, 2 replies; 23+ messages in thread
From: Noah Lavine @ 2011-02-13 2:22 UTC (permalink / raw)
To: Andy Wingo; +Cc: guile-devel
[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]
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.lavine@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.lavine@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
>>
>
[-- Attachment #2: 0001-libguile-socket.c-fix-use-of-uninitialized-memory.patch --]
[-- Type: application/octet-stream, Size: 1126 bytes --]
From 6daec8ce9ecc4784a42479d1ad101435a0408ecf Mon Sep 17 00:00:00 2001
From: Noah Lavine <nlavine@haverford.edu>
Date: Sat, 12 Feb 2011 21:05:34 -0500
Subject: [PATCH] * libguile/socket.c: fix use of uninitialized memory.
---
libguile/socket.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/libguile/socket.c b/libguile/socket.c
index aa52cac..d8ab005 100644
--- a/libguile/socket.c
+++ b/libguile/socket.c
@@ -796,6 +796,7 @@ scm_fill_sockaddr (int fam, SCM address, SCM *args, int which_arg,
port = scm_to_int (SCM_CAR (*args));
*args = SCM_CDR (*args);
soka = (struct sockaddr_in *) scm_malloc (sizeof (struct sockaddr_in));
+ memset (soka, '\0', sizeof (struct sockaddr_in));
#ifdef HAVE_STRUCT_SOCKADDR_SIN_LEN
soka->sin_len = sizeof (struct sockaddr_in);
@@ -1131,6 +1132,8 @@ scm_to_sockaddr (SCM address, size_t *address_size)
{
struct sockaddr_in c_inet;
+ memset (&c_inet, '\0', sizeof (struct sockaddr_in));
+
c_inet.sin_addr.s_addr =
htonl (scm_to_ulong (SCM_SIMPLE_VECTOR_REF (address, 1)));
c_inet.sin_port =
--
1.7.4
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 2:22 ` Noah Lavine
@ 2011-02-13 3:00 ` Noah Lavine
2011-02-13 5:42 ` Ken Raeburn
2011-02-13 20:04 ` Andy Wingo
1 sibling, 1 reply; 23+ messages in thread
From: Noah Lavine @ 2011-02-13 3:00 UTC (permalink / raw)
To: Andy Wingo; +Cc: guile-devel
[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]
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 <noah.b.lavine@gmail.com> 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 <noah.b.lavine@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.lavine@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
>>>
>>
>
[-- Attachment #2: 0001-configure.ac-sometimes-the-sin_len-member-appears-in.patch --]
[-- Type: application/octet-stream, Size: 2060 bytes --]
From 739716df4e54df194a0469f6e12824f7d74b1f02 Mon Sep 17 00:00:00 2001
From: Noah Lavine <nlavine@haverford.edu>
Date: Sat, 12 Feb 2011 21:58:00 -0500
Subject: [PATCH] * configure.ac: sometimes the sin_len member appears in struct
sockaddr_in but not in struct sockaddr
* libguile/socket.c: update to reflect change in configure.ac
---
configure.ac | 3 ++-
libguile/socket.c | 6 +++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 69f35e2..d95cb0e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -955,7 +955,8 @@ AC_CHECK_FUNCS(sethostent gethostent endhostent dnl
# struct sockaddr field sin_len is only present on BSD systems.
# On 4.4BSD apparently a #define SIN_LEN exists, but on other BSD systems
# (eg. FreeBSD 4.9) it doesn't and we must use this configure check
-AC_CHECK_MEMBERS([struct sockaddr.sin_len],,,
+# On Mac OS X, the field only appears in struct sockaddr_in
+AC_CHECK_MEMBERS([struct sockaddr.sin_len, struct sockaddr_in.sin_len],,,
[#ifdef HAVE_SYS_TYPES_H
#include <sys/types.h>
#endif
diff --git a/libguile/socket.c b/libguile/socket.c
index d8ab005..4f9dafc 100644
--- a/libguile/socket.c
+++ b/libguile/socket.c
@@ -798,7 +798,7 @@ scm_fill_sockaddr (int fam, SCM address, SCM *args, int which_arg,
soka = (struct sockaddr_in *) scm_malloc (sizeof (struct sockaddr_in));
memset (soka, '\0', sizeof (struct sockaddr_in));
-#ifdef HAVE_STRUCT_SOCKADDR_SIN_LEN
+#ifdef HAVE_STRUCT_SOCKADDR_SIN_LEN || HAVE_STRUCT_SOCKADDR_IN_SIN_LEN
soka->sin_len = sizeof (struct sockaddr_in);
#endif
soka->sin_family = AF_INET;
@@ -1134,6 +1134,10 @@ scm_to_sockaddr (SCM address, size_t *address_size)
memset (&c_inet, '\0', sizeof (struct sockaddr_in));
+#ifdef HAVE_STRUCT_SOCKADDR_SIN_LEN || HAVE_STRUCT_SOCKADDR_IN_SIN_LEN
+ c_inet.sin_len = sizeof (struct sockaddr_in);
+#endif
+
c_inet.sin_addr.s_addr =
htonl (scm_to_ulong (SCM_SIMPLE_VECTOR_REF (address, 1)));
c_inet.sin_port =
--
1.7.4
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 3:00 ` Noah Lavine
@ 2011-02-13 5:42 ` Ken Raeburn
2011-02-13 13:55 ` Noah Lavine
0 siblings, 1 reply; 23+ messages in thread
From: Ken Raeburn @ 2011-02-13 5:42 UTC (permalink / raw)
To: Noah Lavine; +Cc: guile-devel
What platforms have sin_len in the generic sockaddr structure? The one I've always seen is sa_len, and that's consistent with sa_family in terms of field name prefixes.
sockaddr -> sa_
sockaddr_in -> sin_
sockaddr_in6 -> sin6_
sockaddr_storage -> ss_
I suspect you'd do fine if you ditched the test for sockaddr.sin_len and tested either sockaddr_in.sin_len or sockaddr.sa_len. (And I'd expect an OS to be consistent as to whether the _len field exists for each of the various socket address structures.)
At first glance, the IPv6 flavor of the code looks okay on this score...
Ken
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 5:42 ` Ken Raeburn
@ 2011-02-13 13:55 ` Noah Lavine
2011-02-13 13:57 ` Noah Lavine
2011-02-13 18:34 ` Ken Raeburn
0 siblings, 2 replies; 23+ messages in thread
From: Noah Lavine @ 2011-02-13 13:55 UTC (permalink / raw)
To: Ken Raeburn; +Cc: guile-devel
Hello,
On Sun, Feb 13, 2011 at 12:42 AM, Ken Raeburn <raeburn@raeburn.org> wrote:
> What platforms have sin_len in the generic sockaddr structure? The one I've always seen is sa_len, and that's consistent with sa_family in terms of field name prefixes.
>
> sockaddr -> sa_
> sockaddr_in -> sin_
> sockaddr_in6 -> sin6_
> sockaddr_storage -> ss_
>
> I suspect you'd do fine if you ditched the test for sockaddr.sin_len and tested either sockaddr_in.sin_len or sockaddr.sa_len. (And I'd expect an OS to be consistent as to whether the _len field exists for each of the various socket address structures.)
OS X, which I use, has a somewhat weird field-naming situation. The
generic sockaddr structure has sa_len, but sockaddr_in has a sin_len
field. The code I was fixing is creating a sockaddr_in, so in order to
use the sa_len field I would have had to cast a sockaddr_in to a
sockaddr, and it just seemed cleaner to use the sin_len field. It's no
big deal either way, though - this would affect probably 10 or fewer
lines of code no matter what.
Noah
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 13:55 ` Noah Lavine
@ 2011-02-13 13:57 ` Noah Lavine
2011-02-13 18:34 ` Ken Raeburn
1 sibling, 0 replies; 23+ messages in thread
From: Noah Lavine @ 2011-02-13 13:57 UTC (permalink / raw)
To: Ken Raeburn; +Cc: guile-devel
>> I suspect you'd do fine if you ditched the test for sockaddr.sin_len and tested either sockaddr_in.sin_len or sockaddr.sa_len. (And I'd expect an OS to be consistent as to whether the _len field exists for each of the various socket address structures.)
Oh, and as for why I did this - the current code already contains a
test for a sockaddr.sin_len field. I don't know why it's there, but I
assumed that it was needed on some platform at some point. I left it
there, but added a check for sockaddr_in.sin_len as well.
Noah
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 13:55 ` Noah Lavine
2011-02-13 13:57 ` Noah Lavine
@ 2011-02-13 18:34 ` Ken Raeburn
2011-02-13 20:07 ` Andy Wingo
1 sibling, 1 reply; 23+ messages in thread
From: Ken Raeburn @ 2011-02-13 18:34 UTC (permalink / raw)
To: Noah Lavine; +Cc: guile-devel
On Feb 13, 2011, at 08:55, Noah Lavine wrote:
> OS X, which I use, has a somewhat weird field-naming situation. The
> generic sockaddr structure has sa_len, but sockaddr_in has a sin_len
> field.
No, that's normal for a traditional C/UNIX API. Each structure's field names use a prefix that's an abbreviation for the struct type. So sockaddr_in uses sin_ and not sa_.
If this were a pure C++ API we'd have inheritance and could just specify a length field in the base class "sockaddr" from which the others might be derived. But for this ancient C/UNIX API, we have different structures with different field names, and must cast the pointers.
> The code I was fixing is creating a sockaddr_in, so in order to
> use the sa_len field I would have had to cast a sockaddr_in to a
> sockaddr, and it just seemed cleaner to use the sin_len field. It's no
> big deal either way, though - this would affect probably 10 or fewer
> lines of code no matter what.
Yes, that's fine; just ditch the test for sockaddr (no _in) having a sin_len field.
Ken
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 2:22 ` Noah Lavine
2011-02-13 3:00 ` Noah Lavine
@ 2011-02-13 20:04 ` Andy Wingo
1 sibling, 0 replies; 23+ messages in thread
From: Andy Wingo @ 2011-02-13 20:04 UTC (permalink / raw)
To: Noah Lavine; +Cc: guile-devel
On Sun 13 Feb 2011 03:22, Noah Lavine <noah.b.lavine@gmail.com> writes:
> 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.
Applied, thanks for debugging this.
In the future, please give the function names in the commit logs, and
give the commit a good summary line. See the patch that was pushed to
the repo for an example.
Thanks,
Andy
--
http://wingolog.org/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 18:34 ` Ken Raeburn
@ 2011-02-13 20:07 ` Andy Wingo
2011-02-13 20:10 ` Noah Lavine
0 siblings, 1 reply; 23+ messages in thread
From: Andy Wingo @ 2011-02-13 20:07 UTC (permalink / raw)
To: Ken Raeburn; +Cc: guile-devel
On Sun 13 Feb 2011 19:34, Ken Raeburn <raeburn@raeburn.org> writes:
>> The code I was fixing is creating a sockaddr_in, so in order to
>> use the sa_len field I would have had to cast a sockaddr_in to a
>> sockaddr, and it just seemed cleaner to use the sin_len field. It's no
>> big deal either way, though - this would affect probably 10 or fewer
>> lines of code no matter what.
>
> Yes, that's fine; just ditch the test for sockaddr (no _in) having a sin_len field.
Yes, I think this is the thing to do.
Can you rework your patch, Noah?
Thanks,
Andy
--
http://wingolog.org/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 20:07 ` Andy Wingo
@ 2011-02-13 20:10 ` Noah Lavine
2011-02-13 20:34 ` Noah Lavine
0 siblings, 1 reply; 23+ messages in thread
From: Noah Lavine @ 2011-02-13 20:10 UTC (permalink / raw)
To: Andy Wingo; +Cc: Ken Raeburn, guile-devel
> Yes, I think this is the thing to do.
>
> Can you rework your patch, Noah?
Will do.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 20:10 ` Noah Lavine
@ 2011-02-13 20:34 ` Noah Lavine
2011-02-13 21:10 ` Andy Wingo
0 siblings, 1 reply; 23+ messages in thread
From: Noah Lavine @ 2011-02-13 20:34 UTC (permalink / raw)
To: Andy Wingo; +Cc: Ken Raeburn, guile-devel
[-- Attachment #1: Type: text/plain, Size: 186 bytes --]
Here it is.
On Sun, Feb 13, 2011 at 3:10 PM, Noah Lavine <noah.b.lavine@gmail.com> wrote:
>> Yes, I think this is the thing to do.
>>
>> Can you rework your patch, Noah?
>
> Will do.
>
[-- Attachment #2: 0001-Set-sockaddr_in.sin_len-field-when-it-exists.patch --]
[-- Type: application/octet-stream, Size: 1979 bytes --]
From c2fb79b6b6af4f130d355624be3350d0d9756385 Mon Sep 17 00:00:00 2001
From: Noah Lavine <nlavine@haverford.edu>
Date: Sun, 13 Feb 2011 15:31:32 -0500
Subject: [PATCH] Set sockaddr_in.sin_len field when it exists.
* configure.ac: detect when struct sockaddr_in has a sin_len field.
* libguile/socket.c (scm_to_sockaddr, scm_fill_sockaddr): set the
sin_len field in our struct sockaddr_in when it exists.
---
configure.ac | 2 +-
libguile/socket.c | 6 +++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 69f35e2..6da3e26 100644
--- a/configure.ac
+++ b/configure.ac
@@ -955,7 +955,7 @@ AC_CHECK_FUNCS(sethostent gethostent endhostent dnl
# struct sockaddr field sin_len is only present on BSD systems.
# On 4.4BSD apparently a #define SIN_LEN exists, but on other BSD systems
# (eg. FreeBSD 4.9) it doesn't and we must use this configure check
-AC_CHECK_MEMBERS([struct sockaddr.sin_len],,,
+AC_CHECK_MEMBERS([struct sockaddr_in.sin_len],,,
[#ifdef HAVE_SYS_TYPES_H
#include <sys/types.h>
#endif
diff --git a/libguile/socket.c b/libguile/socket.c
index d8ab005..1059708 100644
--- a/libguile/socket.c
+++ b/libguile/socket.c
@@ -798,7 +798,7 @@ scm_fill_sockaddr (int fam, SCM address, SCM *args, int which_arg,
soka = (struct sockaddr_in *) scm_malloc (sizeof (struct sockaddr_in));
memset (soka, '\0', sizeof (struct sockaddr_in));
-#ifdef HAVE_STRUCT_SOCKADDR_SIN_LEN
+#ifdef HAVE_STRUCT_SOCKADDR_IN_SIN_LEN
soka->sin_len = sizeof (struct sockaddr_in);
#endif
soka->sin_family = AF_INET;
@@ -1134,6 +1134,10 @@ scm_to_sockaddr (SCM address, size_t *address_size)
memset (&c_inet, '\0', sizeof (struct sockaddr_in));
+#ifdef HAVE_STRUCT_SOCKADDR_IN_SIN_LEN
+ c_inet.sin_len = sizeof (struct sockaddr_in);
+#endif
+
c_inet.sin_addr.s_addr =
htonl (scm_to_ulong (SCM_SIMPLE_VECTOR_REF (address, 1)));
c_inet.sin_port =
--
1.7.4
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: Bug in Guile's Posix Networking
2011-02-13 20:34 ` Noah Lavine
@ 2011-02-13 21:10 ` Andy Wingo
0 siblings, 0 replies; 23+ messages in thread
From: Andy Wingo @ 2011-02-13 21:10 UTC (permalink / raw)
To: Noah Lavine; +Cc: Ken Raeburn, guile-devel
On Sun 13 Feb 2011 21:34, Noah Lavine <noah.b.lavine@gmail.com> writes:
> Here it is.
>
> On Sun, Feb 13, 2011 at 3:10 PM, Noah Lavine <noah.b.lavine@gmail.com> wrote:
>>> Yes, I think this is the thing to do.
>>>
>>> Can you rework your patch, Noah?
>>
>> Will do.
>>
Thanks, applied.
Andy
--
http://wingolog.org/
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2011-02-13 21:10 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-07 6:28 Bug in Guile's Posix Networking Noah Lavine
2011-02-07 23:49 ` Andreas Rottmann
2011-02-12 20:47 ` Noah Lavine
2011-02-12 21:02 ` Andy Wingo
2011-02-12 21:35 ` Noah Lavine
2011-02-12 22:00 ` Andy Wingo
2011-02-13 1:22 ` Noah Lavine
2011-02-13 1:45 ` Noah Lavine
2011-02-13 2:22 ` Noah Lavine
2011-02-13 3:00 ` Noah Lavine
2011-02-13 5:42 ` Ken Raeburn
2011-02-13 13:55 ` Noah Lavine
2011-02-13 13:57 ` Noah Lavine
2011-02-13 18:34 ` Ken Raeburn
2011-02-13 20:07 ` Andy Wingo
2011-02-13 20:10 ` Noah Lavine
2011-02-13 20:34 ` Noah Lavine
2011-02-13 21:10 ` Andy Wingo
2011-02-13 20:04 ` Andy Wingo
2011-02-12 11:26 ` Andy Wingo
2011-02-12 20:33 ` Noah Lavine
2011-02-12 20:59 ` Andy Wingo
2011-02-12 21:00 ` Noah Lavine
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).