[Ecls-list] ECL quicklisp bug report - Cause found, fix needed

Marko Kocić marko.kocic at gmail.com
Wed Jan 19 15:26:48 UTC 2011


I *think* I found the cause of the bug, but don't know how to fix it :)

It boils down to the buffer being created like:
> (deftype octet ()
  '(unsigned-byte 8))

OCTET
>
(defun make-octet-vector (size)
  (make-array size :element-type 'octet
              :initial-element 0))

Later on, connection is opened like this.

  (:implementation ecl
    (let* ((endpoint (ql-ecl:host-ent-address
                      (ql-ecl:get-host-by-name host)))
           (socket (make-instance 'ql-ecl:inet-socket
                                  :protocol :tcp
                                  :type :stream)))
      (ql-ecl:socket-connect socket endpoint port)
      (ql-ecl:socket-make-stream socket
                                 :element-type '(unsigned-byte 8)
                                 :input t
                                 :output t
                                 :buffering :full)))

As you can see both should have element-type '(unsigned-byte 8).
But changed ql code of refill method to print connection object and
its stream-element-type I got the following:

(print c)
#<i/o win32 socket stream "FD-STREAM">
(print (stream-element-type c))
CHARACTER

Which means that socket stream has different element-type (CHARACTER)
then specified '(unsigned-byte 8), so read-sequence call fails.

I can confirm that it happens only on mingw, on both unicode and
non-unicode builds.
Linux version of ECL is not affected.

Hope that this provides enough information for fixing this error. I
looked at the source code, but with no much luck.

As a tangent note:
It took me lot of patience and (print ) debugging to track the exact
form that caused the error.
Would it be possible that information like that is easier to find.
Backtrace was unusable, since it reported only the function that I
called on the repl.

One thing that Java got right is the availability of their stacktraces
where one can see exact line where error occured.


Regards,
Marko Kocić


On Mon, Jan 17, 2011 at 10:16 PM, Marko Kocić <marko.kocic at gmail.com> wrote:
> The error is the same when doing only (ql:update-client), so it doesn't do
> anything with packages themselves. I saw the same error when trying out some
> examples from drakma home page. Given that, I assume it has something to do
> with windows networking, since on gentoo I don't get these errors, and ECL
> is built with same options.
>
> On 17 Jan 2011 21:29, "Juan Jose Garcia-Ripoll"
> <juanjose.garciaripoll at googlemail.com> wrote:
>




More information about the ecl-devel mailing list