[Openmcl-devel] CLX crash - crash harder - burn

[Gary Byers]

My guess seems to have been at least half right.

CLX uses the low-level functions CCL:STREAM-READ-IVECTOR and
CCL:STREAM-WRITE-IVECTOR to do low-level transfer of octets
between a stream and a (SIMPLE-ARRAY <immediate-type> (*)).
Those functions are actually documented and somewhat useful.

BLTing octets between a stream's buffer and a SIMPLE-BASE-STRING
via these functions used to be well-defined (since the string
was just a sequence of octets.)  It's less well-defined now,
since (a) the internal representation of a string doesn't
exactly correspond to most external representations and (b)
variable-length character encodings can further confuse the
issue.

Fascinating as that may (or may not ...) be, the problem exposed in
the CLX case included some confusion over whether the socket used
to communicate with the X server was a binary stream.  Using 
CCL:STREAM-READ-IVECTOR to read from the socket into a a vector
of (UNSIGNED-BYTE 8)s wound up calling a method that treated
the target vector as if it were a string (and expanded each octet
from the stream into a 32-bit character, filling the buffer with
garbage and stepping on anything near it in memory, leading to
the kinds of symptoms that you reported.)

I think that this is straightend out in CVS now.

On Mon, 15 Jan 2007, Gary Byers wrote:

> My first guess is that something that used to work when characters
> were 8 bits wide and strings were vectors of 8-bit char-codes is
> failing in a world where characters are basically 32 bits wide;
> something's corrupting memory (among other problems), and enabling
> some consistency checks in the GC causes things like:
>
> Header not expected : 0x6300000065
>
> That "unexpected header" looks suspiciously like #\e and #\c, which
> tends to support that theory.
>
> I'd expect that to fail in a similar way on recent PPC versions as
> well, but haven't checked that.
>
> More caffeine will be required to actually find the problem, but
> my guess is that code that does string I/O over the server socket
> is doing low-level things that only worked when charaters were
> 8 bits wide.
>
>
> On Mon, 15 Jan 2007, Henry Irvine wrote:
>
>> Just a guess, but since this all seems to work on the ppc port of
>> open mcl, I believe that what follows is a problem with openmcl
>> rather than clx...
>>
>> System details:
>> openmcl with cvs updates current to 14 Jan,
>> clx -- fresh download off of clozure, same error happens with a
>> current checkout of the telent source.
>> mac-pro with os version 10.4.8
>>
>> details from debugger output are in the following paste...
>>
>> http://paste.lisp.org/display/35398
>>
>> I am not sure how to narrow down what is actually breaking though.
>>
>> Henry Irvine
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>