[Openmcl-devel] Exception in foreign context

[Gary Byers]

On Sun, 13 Sep 2009, Patrick May wrote:

[...]
>
> And this in the output log (I'm running via detachtty, if that makes a
> difference):
>
> Welcome to Clozure Common Lisp Version 1.3-r12755M  (LinuxX8664)!
> ? STRING-OUTPUT-STREAM  #x300041A9E7CD> is not of the expected type
> STRUCTURE.#<STRING-OUTPUT-STREAM  #x300041A9E7CD> is not of the
> expected type ST
> RUCTURE.Error:
>  is not of the expected type STRUCTURE.
> > Error: value #<STRING-OUTPUT-STREAM  #x30004197E41D> is not of the
> expected ty
> pe STRUCTURE.
> > While executing: CCL::CREATE-STRING-OUTPUT-STREAM-IOBLOCK
> > Error: value #<STRING-OUTPUT-STREAM  #x30004197E41D> is not of the
> expected ty
> pe STRUCTURE.
> > While executing: CCL::CREATE-STRING-OUTPUT-STREAM-IOBLOCK
> > Error: value #<STRING-OUTPUT-STREAM  #x30004197E41D> is not of the
> expected ty
> pe STRUCTURE.
> > While executing: CCL::CREATE-STRING-OUTPUT-STREAM-IOBLOCK, in
> process Hunchent
> oot worker (client: 67.86.101.207:62566)(28).
> , in process Hunchentoot worker (client: 67.86.101.207:62564)(26).
> , in process Hunchentoot listener (*:8080)(3).
>
> > Error: value #<STRING-OUTPUT-STREAM  #x30004197E41D> is not of the
> expected type STRUCTURE.
> > While executing: CCL::CREATE-STRING-OUTPUT-STREAM-IOBLOCK, in
> process Hunchentoot worker (client: 67.86.101.207:62567)(29).


This rings a bell; see:

<http://clozure.com/pipermail/openmcl-devel/2009-April/009117.html>

My recollection of that problem is that:

  - CCL expects a STRING-OUTPUT-STREAM to be (mostly) thread-private;
    in particular it expects a STRING-OUTPUT-STREAM to be closed from
    the same thread that created it.  (A lot of that has to do with
    being able to cheaply recycle some of the resources that STRING-
    OUTPUT-STREAMS use and the use of a thread-specific special variable
    to do that recycling.)

  - The problem was occurring in that case/at that time not because code
    was violating the assumption, but because a threading library that
    Hunchentoot used was creating threads without "standard initial bindings"
    (including the binding of the thread-local variable used to do the
    freelisting.)

The threads library (Bordeaux ?) was changed and the problem went away.

The assumption that STRING-OUTPUT-STREAMs are short-lived and mostly thread-private
still seems reasonable (in the sense that it's typical and reasonable to optimize
for), but it's not clear that violating that assumption should lead to memory
corruption.  That hasn't been fixed (partly because the Hunchentoot problem
seemed to be triggered by the threads library behavior and partly because the
idea of closing a STRING-OUTPUT-STREAM from a thread other than the one that
created it seemed like a pretty bizarre thing to do.)  It still seems a bit
bizzarre, but it's probably equally bizarre to not handle that case more sanely.

In any case, it seems believable that you're running into the same problem; if
so, using a newer version of the (Bordeaux ?) threads library will likely fix it.