- usocket-devel - mailman3.common-lisp.net

Lispworks Windows UDP behaviour
by Frank James 27 May '15

27 May '15

I've been testing some UDP codes on Lispworks (personal 32bit Windows version) and have encountered some undocumented behaviour, I think it's a matter of opinion whether it's a bug or not but it should probably have a sentence or two documenting it somewhere. Basically I'm sending a UDP packet to a host and listening for a reply, using socket-send and socket-receive. If the host in question is not listening for UDP traffic on that particular port, the Windows socket API says it should return an ECONNRESET error immediately on the socket-receive call, this is indicated by a -1 return value from the underlying recvfrom call. When this happens the Lispworks backend code returns a length of -1 (and buffer nil). This is perfectly acceptable behaviour I think (although it'd be somewhat nicer to signal an error, but that's a matter of taste). But it should be documented that checking the length here is the correct way to detect an error occurred. Example code would be something like: (let ((sock (usocket:socket-connect "localhost" 1234 :protocol :datagram :element-type '(unsigned-byte 8)))) (unwind-protect (progn (usocket:socket-send sock (make-array 16 :element-type '(unsigned-byte 8) :initial-element 0) 16) (let ((buffer (make-array 16 :element-type '(unsigned-byte 8) :initial-element 0))) (usocket:socket-receive sock buffer 16))) (usocket:socket-close sock))) What is somewhat more annoying is that the socket object remains in a :READ state. This means that a polling loop using wait-for-input spins continuously, with each socket-receive returning -1 (as explained above). Probably the socket state should be cleared if a socket-receive fails. Apologies if this is all well-known to those reading this list, but it caused me 10 minutes of head scratching earlier today and thought it was worth mentioning. Frank.

2 7

[ANN] usocket 0.6.3
by Chun Tian (binghe) 23 May '15

23 May '15

Dear Lispers, We’re glad to announce the usocket 0.6.3, a small patch release after 0.6.2 (April 2015). Changes in this release: * Bugfix: [CCL] Further fixed CCL-1.11 compatibility and a typo in SOCKET-CONNECT for old CCL versions. * Bugfix: [ECL] Fixed build in some versions. * Bugfix: [LispWorks] SOCKET-SEND and SOCKET-RECEIVE now throw conditions if something goes wrong. Also, IPv6 is partial supported in SBCL (1.2.5+) and CCL (1.11), now we’re working on more platforms, especially LispWorks and Allegro CL. Special thanks to Mark H. David, Frank James and other people who provided valuable bug reports, test cases and suggestions. As usual, if you want to download this release, please check http://common-lisp.net/project/usocket/releases/ or just wait for next Quicklisp monthly dist updates. The API documentation page was here: http://common-lisp.net/project/usocket/api-docs.shtml Any feedback - bugs or hugs - is greatly appreciated. Anyone is welcome to send pull request to our Git [1]: https://github.com/usocket/usocket.git Regards, Chun Tian (binghe) USOCKET Team

1 0

Re: [Usocket-devel] use of unexported symbols in backend/openmcl.lisp
by Chun Tian (binghe) 22 May '15

22 May '15

Hi, Today I have modified USOCKET to depend on this new :IPv6 feature. And now I’ve created a new backend file “clozure.lisp” [1] for holding all functions specific to CCL-1.11, I think this is many people wanted for years. The old backend file “openmcl.lisp” is not only for old CCL versions, but new backend is only for new CCL versions. P. S. I’m preparing a new release 0.6.3 for all recent changes. Regards, Chun [1] https://github.com/usocket/usocket/commit/059d9747c62ac92a525de955d5fb7441d… Il giorno 20/dic/2014, alle ore 04:49, R. Matthew Emerson <rme(a)clozure.com> ha scritto: > >> On Dec 19, 2014, at 3:40 AM, Hans Hübner <hans.huebner(a)gmail.com> wrote: >> >> Hi Chun, >> >> Matthew said that he intends to add an IPv6 *feature* to CCL, which might be even more appropriate. Matthew, did you decide on the feature keyword yet? > > I decided to put :ipv6 on *features* (which is also what Allegro CL uses). >

1 0

Re: [Openmcl-devel] bug with usocket and/or trunk ccl - "error #22"
by Chun Tian (binghe) 20 May '15

20 May '15

Issue fixed, problem is in usocket (of course). The created server socket is IPv4, but client socket is IPv6, that’s why the sending data cannot be received … now using “localhost” they’re both IPv6 sockets. I’ve committed to Git master [1], this time the original test code runs perfectly. Thanks to everyone, let me know if there’re still other issues for CCL 1.11. -- Chun [1] https://github.com/usocket/usocket/commit/966de96f5f1954f7f5aa91e1191317e12… Il giorno 20/mag/2015, alle ore 20:44, Karsten Poeck <Karsten.Poeck(a)gmail.com> ha scritto: > On 20.05.15 20:25, Chun Tian (binghe) wrote: >> Hi, >> >> I was working on this issue since 10 hours ago when I firstly saw the mail. I’ve already committed an initial fix [1] to usocket Git master, in which I handled two compatibility issues between usocket and ccl-1.11, and now there’s no error reported when creating and sending sockets. But it seems that CCL::SEND-TO cannot actually send out the data to a “connected” UDP socket, as a result the test code is blocked at (usocket:socket-receive …). >> >> Usocket’s backend code for CCL is basically just a wrapper (even more true for ccl-1.11), my next step is to remove all usocket wrappers and only use CCL’s native API to reproduce the same issue. I’ll submit trac tickets to CCL if I found something. >> >> Regards, >> >> Chun >> > > Looking at the code for socket-connect in current usocket from quicklisp there are a 2 things that leaved me slightly puzzled. > > The signature is: > (defun socket-connect (host port &key (protocol :stream) element-type > timeout deadline nodelay > local-host local-port) > > But later it does (host-to-hbo local-host). This fails miserably when local-host is nil, which seems to be an ok use of it (and happens in our example for the client socket) > > It also does pass :address-family (openmcl-socket:socket-address-family remote) to openmcl-socket:make-socket. > > But remote is only set, when (and host port) otherwise it stays nil, so the socket-address will also fail. This happens for me in the server socket. > > Looking at your commit you seem to have addressed this already though :-) > > Karsten > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel(a)clozure.com > https://lists.clozure.com/mailman/listinfo/openmcl-devel

1 0

Re: [Openmcl-devel] bug with usocket and/or trunk ccl - "error #22"
by Chun Tian (binghe) 20 May '15

20 May '15

CCL 1.11’s make-udp-socket function will call "%socket-connect” if keyword arguments remote-host and remote-port are provided with make-socket. This is new in CCL 1.11: (defun make-udp-socket (&rest keys &key (fd -1) (connect :active) (address-family :internet) remote-host remote-port &allow-other-keys) (unwind-protect (let (socket) (when (< fd 0) (setq fd (socket-call nil "socket" (c_socket (ecase address-family (:internet #$PF_INET) (:internet6 #$PF_INET6)) #$SOCK_DGRAM #$IPPROTO_UDP)))) (setq socket (make-instance 'udp-socket :device fd :keys keys)) (apply #'set-socket-options socket keys) (when (and (eql connect :active) remote-host remote-port) (%socket-connect fd (apply #'resolve-address :host remote-host :port remote-port :allow-other-keys t keys) nil)) (setq fd -1) socket) (unless (< fd 0) (fd-close fd)))) Il giorno 20/mag/2015, alle ore 20:00, Patrick Stein <clozure(a)nklein.com> ha scritto: > usocket from the current quicklisp dist is calling (ccl::inet-connect ...) with a few parameters it gets by calling other unexported CCL functions. > > Just this line is sufficient to get to the (first?) problem: >> (usocket:socket-connect "localhost" 1111 :protocol ':datagram) > > In a quick glance around trunk, I didn't see where make-udp-socket would invoke connect(2) or any way to do it after-the-fact. > > -- Patrick <pat(a)nklein.com> > > On May 20, 2015, at 12:49 PM, R. Matthew Emerson <rme(a)clozure.com> wrote: > >> I can try to look at it. What version of usocket are you using? Is there a place I can get it easily so I can try to run your test case and duplicate the problem? >> >> >>> On May 19, 2015, at 6:10 PM, Mark H. David <mhd(a)yv.org> wrote: >>> >>> This works on an earlier CCL: >>> Welcome to Clozure Common Lisp Version 1.10-r16196 (LinuxX8664)! >>> >>> (let* ((host "localhost") >>> (port 1111) >>> (server-sock >>> (usocket:socket-connect nil nil :protocol ':datagram :local-host host :local-port port)) >>> (client-sock >>> (usocket:socket-connect host port :protocol ':datagram)) >>> (octet-vector >>> (make-array 2 :element-type '(unsigned-byte 8) :initial-contents `(,(char-code #\O) ,(char-code #\K)))) >>> (recv-octet-vector >>> (make-array 2 :element-type '(unsigned-byte 8)))) >>> (usocket:socket-send client-sock octet-vector 2) >>> (usocket:socket-receive server-sock recv-octet-vector 2) >>> (prog1 (and (equalp octet-vector recv-octet-vector) >>> recv-octet-vector) >>> (usocket:socket-close server-sock) >>> (usocket:socket-close client-sock))) >>> >>> => >>> >>> #(79 75) >>> >>> >>> >>> On trunk CCL, updated/built on 5/19/15: >>> Welcome to Clozure Common Lisp Version 1.11-dev-r16393M-trunk (DarwinX8664)! >>> >>> It gets an error: >>> >>>> Debug: The condition Invalid argument (error #22) during attempt to connect to [unparsed, AF 2] occurred. >>>> While executing: (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER), in process repl-thread(12). >>>> Type :POP to abort, :R for a list of available restarts. >>>> Type :? for other options. >>> 1 > :b >>> >>> (24034210) : 0 (FUNCALL #'#<(:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER)>) 53 >>> (24034230) : 1 (FUNCALL #'#<SWANK/BACKEND:CALL-WITH-DEBUGGER-HOOK> NIL #<COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER) #x302002623FFF>) 181 >>> (240342B8) : 2 (CALL-WITH-DEBUGGER-HOOK NIL #<COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER) #x302002623FFF>) 181 >>> (240342E8) : 3 (INVOKE-DEFAULT-DEBUGGER #<USOCKET:UNKNOWN-ERROR #x30200250C31D>) 189 >>> (24034308) : 4 (SWANK-DEBUGGER-HOOK #<USOCKET:UNKNOWN-ERROR #x30200250C31D> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x3020008ADAEF>) 565 >>> (24034338) : 5 (BREAK-LOOP-HANDLE-ERROR #<USOCKET:UNKNOWN-ERROR #x30200250C31D> 75524225) 637 >>> (240343E0) : 6 (%ERROR #<USOCKET:UNKNOWN-ERROR #x30200250C31D> (:SOCKET NIL :REAL-ERROR #<SOCKET-CREATION-ERROR #x30200250D79D>) 75524225) 333 >>> (24034408) : 7 (RAISE-ERROR-FROM-ID :UNKNOWN NIL #<SOCKET-CREATION-ERROR #x30200250D79D>) 213 >>> (24034438) : 8 (HANDLE-CONDITION #<SOCKET-CREATION-ERROR #x30200250D79D> NIL) 709 >>> (24034470) : 9 (FUNCALL #'#<(:INTERNAL USOCKET:SOCKET-CONNECT)> #<SOCKET-CREATION-ERROR #x30200250D79D>) 61 >>> (24034490) : 10 (SIGNAL #<SOCKET-CREATION-ERROR #x30200250D79D>) 981 >>> (240344E8) : 11 (%ERROR #<SOCKET-CREATION-ERROR #x30200250D79D> NIL 75524258) 117 >>> (24034510) : 12 (SOCKET-ERROR NIL "connect" 22 NIL :CONNECT-ADDRESS #<SOCKET-ADDRESS [unparsed, AF 2]>) 1053 >>> (24034580) : 13 (INET-CONNECT 20 16777343 22276 NIL) 637 >>> (240345C8) : 14 (SOCKET-CONNECT "localhost" 1111 :PROTOCOL :DATAGRAM :ELEMENT-TYPE NIL :TIMEOUT NIL :DEADLINE NIL :NODELAY NIL :LOCAL-HOST NIL :LOCAL-PORT NIL) 1149 >>> (24034690) : 15 (FUNCALL #'#<Anonymous Function #x30200250E67F>) 149 >>> (240346A8) : 16 (CHEAP-EVAL (LET* (# # # # # ...) (USOCKET:SOCKET-SEND CLIENT-SOCK OCTET-VECTOR 2) (USOCKET:SOCKET-RECEIVE SERVER-SOCK RECV-OCTET-VECTOR 2) (PROG1 # # #))) 101 >>> >>> >>> >>> What's up with that? >>> >>> Thanks, >>> >>> Mark >>> >>> >> >> > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel(a)clozure.com > https://lists.clozure.com/mailman/listinfo/openmcl-devel

1 0

bug with usocket and/or trunk ccl - "error #22"
by Mark H. David 20 May '15

20 May '15

This works on an earlier CCL: Welcome to Clozure Common Lisp Version 1.10-r16196 (LinuxX8664)! (let* ((host "localhost") (port 1111) (server-sock (usocket:socket-connect nil nil :protocol ':datagram :local-host host :local-port port)) (client-sock (usocket:socket-connect host port :protocol ':datagram)) (octet-vector (make-array 2 :element-type '(unsigned-byte 8) :initial-contents `(,(char-code #\O) ,(char-code #\K)))) (recv-octet-vector (make-array 2 :element-type '(unsigned-byte 8)))) (usocket:socket-send client-sock octet-vector 2) (usocket:socket-receive server-sock recv-octet-vector 2) (prog1 (and (equalp octet-vector recv-octet-vector) recv-octet-vector) (usocket:socket-close server-sock) (usocket:socket-close client-sock))) => #(79 75) On trunk CCL, updated/built on 5/19/15: Welcome to Clozure Common Lisp Version 1.11-dev-r16393M-trunk (DarwinX8664)! It gets an error: > Debug: The condition Invalid argument (error #22) during attempt to connect to [unparsed, AF 2] occurred. > While executing: (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER), in process repl-thread(12). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > :b (24034210) : 0 (FUNCALL #'#<(:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER)>) 53 (24034230) : 1 (FUNCALL #'#<SWANK/BACKEND:CALL-WITH-DEBUGGER-HOOK> NIL #<COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER) #x302002623FFF>) 181 (240342B8) : 2 (CALL-WITH-DEBUGGER-HOOK NIL #<COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER) #x302002623FFF>) 181 (240342E8) : 3 (INVOKE-DEFAULT-DEBUGGER #<USOCKET:UNKNOWN-ERROR #x30200250C31D>) 189 (24034308) : 4 (SWANK-DEBUGGER-HOOK #<USOCKET:UNKNOWN-ERROR #x30200250C31D> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x3020008ADAEF>) 565 (24034338) : 5 (BREAK-LOOP-HANDLE-ERROR #<USOCKET:UNKNOWN-ERROR #x30200250C31D> 75524225) 637 (240343E0) : 6 (%ERROR #<USOCKET:UNKNOWN-ERROR #x30200250C31D> (:SOCKET NIL :REAL-ERROR #<SOCKET-CREATION-ERROR #x30200250D79D>) 75524225) 333 (24034408) : 7 (RAISE-ERROR-FROM-ID :UNKNOWN NIL #<SOCKET-CREATION-ERROR #x30200250D79D>) 213 (24034438) : 8 (HANDLE-CONDITION #<SOCKET-CREATION-ERROR #x30200250D79D> NIL) 709 (24034470) : 9 (FUNCALL #'#<(:INTERNAL USOCKET:SOCKET-CONNECT)> #<SOCKET-CREATION-ERROR #x30200250D79D>) 61 (24034490) : 10 (SIGNAL #<SOCKET-CREATION-ERROR #x30200250D79D>) 981 (240344E8) : 11 (%ERROR #<SOCKET-CREATION-ERROR #x30200250D79D> NIL 75524258) 117 (24034510) : 12 (SOCKET-ERROR NIL "connect" 22 NIL :CONNECT-ADDRESS #<SOCKET-ADDRESS [unparsed, AF 2]>) 1053 (24034580) : 13 (INET-CONNECT 20 16777343 22276 NIL) 637 (240345C8) : 14 (SOCKET-CONNECT "localhost" 1111 :PROTOCOL :DATAGRAM :ELEMENT-TYPE NIL :TIMEOUT NIL :DEADLINE NIL :NODELAY NIL :LOCAL-HOST NIL :LOCAL-PORT NIL) 1149 (24034690) : 15 (FUNCALL #'#<Anonymous Function #x30200250E67F>) 149 (240346A8) : 16 (CHEAP-EVAL (LET* (# # # # # ...) (USOCKET:SOCKET-SEND CLIENT-SOCK OCTET-VECTOR 2) (USOCKET:SOCKET-RECEIVE SERVER-SOCK RECV-OCTET-VECTOR 2) (PROG1 # # #))) 101 What's up with that? Thanks, Mark

3 2

bug with usocket and/or trunk ccl - "error #22"
by Mark H. David 19 May '15

19 May '15

This works on an earlier CCL: Welcome to Clozure Common Lisp Version 1.10-r16196 (LinuxX8664)! (let* ((host "localhost") (port 1111) (server-sock (usocket:socket-connect nil nil :protocol ':datagram :local-host host :local-port port)) (client-sock (usocket:socket-connect host port :protocol ':datagram)) (octet-vector (make-array 2 :element-type '(unsigned-byte 8) :initial-contents `(,(char-code #\O) ,(char-code #\K)))) (recv-octet-vector (make-array 2 :element-type '(unsigned-byte 8)))) (usocket:socket-send client-sock octet-vector 2) (usocket:socket-receive server-sock recv-octet-vector 2) (prog1 (and (equalp octet-vector recv-octet-vector) recv-octet-vector) (usocket:socket-close server-sock) (usocket:socket-close client-sock))) => #(79 75) On trunk CCL, updated/built on 5/19/15: Welcome to Clozure Common Lisp Version 1.11-dev-r16393M-trunk (DarwinX8664)! It gets an error: > Debug: The condition Invalid argument (error #22) during attempt to connect to [unparsed, AF 2] occurred. > While executing: (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER), in process repl-thread(12). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > :b (24034210) : 0 (FUNCALL #'#<(:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER)>) 53 (24034230) : 1 (FUNCALL #'#<SWANK/BACKEND:CALL-WITH-DEBUGGER-HOOK> NIL #<COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER) #x302002623FFF>) 181 (240342B8) : 2 (CALL-WITH-DEBUGGER-HOOK NIL #<COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER) #x302002623FFF>) 181 (240342E8) : 3 (INVOKE-DEFAULT-DEBUGGER #<USOCKET:UNKNOWN-ERROR #x30200250C31D>) 189 (24034308) : 4 (SWANK-DEBUGGER-HOOK #<USOCKET:UNKNOWN-ERROR #x30200250C31D> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x3020008ADAEF>) 565 (24034338) : 5 (BREAK-LOOP-HANDLE-ERROR #<USOCKET:UNKNOWN-ERROR #x30200250C31D> 75524225) 637 (240343E0) : 6 (%ERROR #<USOCKET:UNKNOWN-ERROR #x30200250C31D> (:SOCKET NIL :REAL-ERROR #<SOCKET-CREATION-ERROR #x30200250D79D>) 75524225) 333 (24034408) : 7 (RAISE-ERROR-FROM-ID :UNKNOWN NIL #<SOCKET-CREATION-ERROR #x30200250D79D>) 213 (24034438) : 8 (HANDLE-CONDITION #<SOCKET-CREATION-ERROR #x30200250D79D> NIL) 709 (24034470) : 9 (FUNCALL #'#<(:INTERNAL USOCKET:SOCKET-CONNECT)> #<SOCKET-CREATION-ERROR #x30200250D79D>) 61 (24034490) : 10 (SIGNAL #<SOCKET-CREATION-ERROR #x30200250D79D>) 981 (240344E8) : 11 (%ERROR #<SOCKET-CREATION-ERROR #x30200250D79D> NIL 75524258) 117 (24034510) : 12 (SOCKET-ERROR NIL "connect" 22 NIL :CONNECT-ADDRESS #<SOCKET-ADDRESS [unparsed, AF 2]>) 1053 (24034580) : 13 (INET-CONNECT 20 16777343 22276 NIL) 637 (240345C8) : 14 (SOCKET-CONNECT "localhost" 1111 :PROTOCOL :DATAGRAM :ELEMENT-TYPE NIL :TIMEOUT NIL :DEADLINE NIL :NODELAY NIL :LOCAL-HOST NIL :LOCAL-PORT NIL) 1149 (24034690) : 15 (FUNCALL #'#<Anonymous Function #x30200250E67F>) 149 (240346A8) : 16 (CHEAP-EVAL (LET* (# # # # # ...) (USOCKET:SOCKET-SEND CLIENT-SOCK OCTET-VECTOR 2) (USOCKET:SOCKET-RECEIVE SERVER-SOCK RECV-OCTET-VECTOR 2) (PROG1 # # #))) 101 What's up with that? Thanks, Mark

1 0

[ANNOUNCE] usocket 0.6.2
by Chun Tian (binghe) 20 Apr '15

20 Apr '15

Dear lispers, We announce the usocket 0.6.2 release, a small patch release after 0.6.1 (June 2013). Changes in this release: * Bugfix: [CCL] Fixed CCL-1.11 compatibility. * Bugfix: [ECL] Fixed compatibility on recent versions. * Bugfix: [LispWorks] Added support address-in-use-error condition on LW/Win32. (patch from Sergey Katrevich). As usual, if you want to download this release, please check http://common-lisp.net/project/usocket/releases/ or just wait for next Quicklisp monthly dist updates. The API documentation page was here: http://common-lisp.net/project/usocket/api-docs.shtml As usual, any feedback - bugs or hugs - is greatly appreciated. We have turned to use Git [1] instead of SVN, so maybe now it’s easier to receive patches. P. S. Something currently still in progress (will be released soon): * New feature: IPv6 support (by Hans Hübner) Regards, Chun Tian (binghe) USOCKET Team [1] https://github.com/usocket/usocket.git

1 0

status of openmcl and :ccl-1.11-sockets feature
by Mark H. David 16 Apr '15

16 Apr '15

I see there's code to add feature :ccl-1.11-sockets and to use it via a read-time feature check in the same file. The file is backend/openmcl.lisp. I don't think this can work reliably. It seems to work, but I don't think Common Lisp guarantees it. The code is (eval-when (:compile-toplevel :load-toplevel :execute) (when (find-class 'ccl::ip6-socket-address nil) (pushnew :ccl-1.11-sockets *features*))) I think a much more robust solution would be for this to go in an earlier file that is guaranteed to be loaded before backend/openmcl.lisp is compiled. Can one of the developers review this? Also, any word on when this will propagate to Quicklisp? Thanks, Mark

3 3

Re: [Usocket-devel] [usocket] error with usocket datagram socket sending userial buffers on SBCL 1.2.1 Windows 8 (#1)
by Chun Tian (binghe) 27 Jan '15

27 Jan '15

Hi Ezra, I don’t understand this part in your test code: (usocket:socket-send socket (userial:make-buffer) 32768 :host remote-host :port remote-port) What’s done by (userial:make-buffer) is a empty buffer, but you send its contents as a message length of 32768. USOCKET passed the created array directly to underlying SB-BSD-SOCKETS:SOCKET-SEND in this case, but I think SBCL actually didn’t allocate any memory, so there’s a memory access issue when it trys to find the 32768 elements. Here is the definition of USERIAL:MAKE-BUFFER: (defun make-buffer (&optional (initial-capacity +default-buffer-capacity+)) "Create an empty BUFFER of a given INITIAL-CAPACITY" (declare (type bufsize initial-capacity) (optimize (speed 3))) (make-array (list initial-capacity) :element-type 'uchar :initial-element 0 :fill-pointer 0 :adjustable t)) I think SBCL has its reason to optimize above calls by not allocating any memory until you start to push the first element in. Maybe SBCL only does it when seeing (optimize (speed 3)), I don’t know... Any way, I can’t say this is either an issue of USERIAL, USOCKET or SBCL, because each of them didn’t do anything unreasonable here… Hope this helps, Chun Il giorno 27/gen/2015, alle ore 23:19, Ezra Rush <notifications(a)github.com> ha scritto: > I apologize if this is actually an issue with userial or Windows. > > Code can be found here: https://gist.github.com/ezrarush/01741135c7141621210c > > Using userial with usocket's datagram socket causes an intermittent error. > > Socket error in "sendto": 10014 (The system detected an invalid pointer address in attempting to use a pointer argument in a call.) > [Condition of type SB-BSD-SOCKETS:SOCKET-ERROR] > > Using an array instead of userial's buffer does not seem to error. > > — > Reply to this email directly or view it on GitHub. >

1 0