[flexi-streams-devel] Re: [hunchentoot-devel] write-sequence to *hunchentoot-stream* on x86_64

Edi Weitz edi at agharta.de
Tue Aug 21 09:54:26 UTC 2007


On Mon, 20 Aug 2007 12:47:06 -0700 (PDT), Jeff Caldwell <jdcal at yahoo.com> wrote:

> Can anyone give me a way to debug the following problem, or tell me
> likely places to investigate?
>
> With Hunchentoot 0.11.1 I have a problem on this machine:
>
> Linux machine-1-name 2.6.18-8.1.8.el5 #1 SMP Mon Jun 25 15:19:07 EDT 2007
> x86_64 x86_64 x86_64 GNU/Linux
>
> but I don't have that problem on this machine:
>
> Linux machine-2-name 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007
> i686 i686 i386 GNU/Linux
>
> I am running LWL Pro 4.3.7.
>
> On the x86_64 machine, every page, even the Hunchentoot default
> page, has some seemingly-random binary data that comes after the
> headers but before the content. This appears in the browser as
> strange characters at the top of the page, often (but not always)
> followed by part or all of the desired web page.  The random binary
> data is not in the content variable that is written to the
> stream. The headers are OK, the content is OK, it is only that there
> is extra binary data between the headers and the content.
>
> I found a workaround. In headers.lisp, in function start-output, in
> the following code, write-sequence is the original code in
> hunchentoot while write-string is the workaround needed to get good
> output and avoid the extraneous binary data between the headers and
> the content.
>
> ...
>     (setf (flexi-stream-external-format *hunchentoot-stream*) 
>           (reply-external-format))
>     ;; now optional content
>     (unless (or (null content) head-request-p)
>       (ignore-errors
> 	#+x86_64RHEL5-workaround
>         (write-string (coerce (loop for c across content 
>                                     collect (code-char c)) 'string)          
>         
>                       *hunchentoot-stream*)
>         #-x86_64RHEL5-workaround
>         (write-sequence content *hunchentoot-stream*)))
>     (when chunkedp
>       ;; turn chunking on after the headers have been sent
>       (setf (chunked-stream-output-chunking-p
>              (flexi-stream-stream *hunchentoot-stream*)) t))
>     *hunchentoot-stream*))
>
> Again, can anyone give me tips on where to look or how to debug the
> problem?

Looks like a possible bug in flexi-streams (/or/ in LWL 4) to me and
should probably be discussed on the corresponding mailing list - see
Cc.  Could you check if the test suite of flexi-streams runs through
on your x86_64 machine?  Are you using the newest version of
flexi-streams?  Could you check if you get the same problems with LWL
5.0.x, maybe using the Personal Edition?  Unfortunately, I don't have
a 64-bit machine yet to check this myself.

Thanks,
Edi.



More information about the Flexi-streams-devel mailing list