[iolib-devel] Strange behaviour of net.smtp-client:send-email

Chun Tian binghe binghe.lisp at gmail.com
Fri Jun 8 16:43:36 UTC 2007


Hi, dear iolib developer

I think you just test net.smtp-client's code on SBCL 32-bit but not on 64-bit,
and LispWorks 64-bit (which I paid $2500 for it in April this year). Let me
test #'net.smtp-client:send-email for you:

On SBCL 1.0.6 32-bit, Linux, everything goes well:

>CL-USER(2): (net.smtp-client::send-email "mail.163.org"
>                                         "binghe at 163.org"
>                                         "sa at 163.org"
>                                         "test mail 1"
>                                         "test from SBCL")
>NIL

The mail.163.org is a sendmail server, and I can receive this mail, but it's
strange that mail.163.org can be resolved to IP address, I cannot find where
you use the net.dns-client to do this.

On SBCL 1.0.6 64-bit, Linux, can't resolv host name, must use IP address:

>CL-USER(2): (net.smtp-client::send-email "mail.163.org"
>                                         "binghe at 163.org"
>                                         "sa at 163.org"
>                                         "test mail 2"
>                                         "test from SBCL")
>debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread
> #<THREAD "initial thread" {10025DF051}>:
> Unhandled memory fault at #x0.

I think this is reasonable, the #'make-smtp-socket function calls #'make-socket,
and #'make-socket didn't call functions in net.dns-client to resolv host name,
and I tried to direct use mail server's IP address, and success.

>CL-USER(2): (net.smtp-client::send-email "192.168.80.2"
>                                         "binghe at 163.org"
>                                         "sa at 163.org"
>                                         "test mail 3"
>                                         "test from SBCL")
>NIL

On LispWorks 64-bit, Linux. (I only have 64-bit version, no 32-bit version),
with two patches cannot work with any of above:

>NET.SMTP-CLIENT 35 > (net.smtp-client::send-email "192.168.80.2"
>                                                  "binghe at 163.org"
>                                                  "sa at 163.org"
>                                                  "test mail 4"
>                                                  "test from lispworks")
>Error: #\2 is not of type INTEGER.
>  1 (abort) Return to level 0.
>  2 Return to top loop level 0.
>Type :b for backtrace, :c <option number> to proceed,  or :? for other options

Strange. the read-from-smtp function:

(defun read-from-smtp (sock)
  (let* ((line (read-line sock))
         (response-code (parse-integer line :start 0 :junk-allowed t)))
    (if (= (char-code (elt line 3)) (char-code #\-))
        (read-from-smtp sock)
        (values response-code line))))

It calls (read-line sock) to read the mail server's return code, LispWorks
translate this into:
 (method stream:stream-read-line (stream:fundamental-stream))
which throw out the above error.

LispWorks think the sock is
  #<active IPv6 stream socket connected to ::ffff:192.168.80.2/25 41900A2C08>,
of class 'socket-stream-internet-active. It's class precedence in LispWorks:

NET.SOCKETS:SOCKET-STREAM-INTERNET-ACTIVE
NET.SOCKETS:ACTIVE-SOCKET
NET.SCOKETS:STREAM-SOCKET
NET.SOCKETS:INTERNET-SOCKET
NET.SOCKETS:SOCKET
IO.STREAMS:DUAL-CHANNEL-SINGLE-FD-MIXIN
IO.STREAMS:DUAL-CHANNEL-GRAY-STREAM
IO.STREAMS:DUAL-CHANNEL-FD-MIXIN
STREAM:FUNDAMENTAL-BINARY-INPUT-STREAM
STREAM:FUNDAMENTAL-BINARY-OUTPUT-STREAM
STREAM:FUNDAMENTAL-CHARACTER-INPUT-STREAM
STREAM:FUNDAMENTAL-INPUT-STREAM
STREAM:FUNDAMENTAL-CHARACTER-OUTPUT-STREAM
STREAM:FUNDAMENTAL-OUTPUT-STREAM
STREAM:FUNDAMENTAL-CHARACTER-STREAM
STREAM:FUNDAMENTAL-BINARY-STREAM
STREAM:FUNDAMENTAL-STREAM
STREAM::STDOBJ-STREAM
STREAM
STANDARD-OBJECT
T

Only STREAM:FUNDAMENTAL-STREAM has a method called stream-read-line, but seems
that it cannot read correctly... I don't know if this is a LispWorks bug or
IOlib bug, can you give some advice?

Thanks!

Chun Tian (binghe)




More information about the iolib-devel mailing list