* 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 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: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 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
* 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-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-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
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).