From edi at agharta.de Tue Aug 21 09:54:26 2007 From: edi at agharta.de (Edi Weitz) Date: Tue, 21 Aug 2007 11:54:26 +0200 Subject: [flexi-streams-devel] Re: [hunchentoot-devel] write-sequence to *hunchentoot-stream* on x86_64 In-Reply-To: <317126.32140.qm@web50601.mail.re2.yahoo.com> (Jeff Caldwell's message of "Mon, 20 Aug 2007 12:47:06 -0700 (PDT)") References: <317126.32140.qm@web50601.mail.re2.yahoo.com> Message-ID: On Mon, 20 Aug 2007 12:47:06 -0700 (PDT), Jeff Caldwell 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. From jdcal at yahoo.com Wed Aug 22 15:17:36 2007 From: jdcal at yahoo.com (Jeff Caldwell) Date: Wed, 22 Aug 2007 08:17:36 -0700 (PDT) Subject: [flexi-streams-devel] Re: [hunchentoot-devel] write-sequence to *hunchentoot-stream* on x86_64 Message-ID: <547171.10237.qm@web50607.mail.re2.yahoo.com> Hi Edi, Thanks for pointing me in a good direction. I hope this ends up in the same thread as your cc from hunchentoot-devel, but here is a summary in case it doesn't: 32-bit LWLPro 4.3.7 ran OK on 32-bit Linux but on x86_64. Hunchentoot returned the headers OK, followed by a block of seemingly-random binary data, followed by the content, which was OK. I found a workaround, using write-string instead of write-sequence to write the content. >Edi wrote: > >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. The flexi-streams test suite ran with all tests passed (3313 of them, if I recall correctly). LWL 5.0.x Personal Edition does not exhibit the problem. I'm using flexi-streams-0.11.2. I suppose the limitation of my workaround (write-string vs write-sequence) is the charset, no UTF? Anything else to be aware of? Maybe I can leverage this app into a nice new 5.0 license, courtesy of my employer. If not, do you have a quick thought regarding where else I might look to change the behavior in 4.3.7? Thanks, Jeff Caldwell ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ From edi at agharta.de Wed Aug 22 16:56:46 2007 From: edi at agharta.de (Edi Weitz) Date: Wed, 22 Aug 2007 18:56:46 +0200 Subject: [flexi-streams-devel] Re: write-sequence to *hunchentoot-stream* on x86_64 In-Reply-To: <547171.10237.qm@web50607.mail.re2.yahoo.com> (Jeff Caldwell's message of "Wed, 22 Aug 2007 08:17:36 -0700 (PDT)") References: <547171.10237.qm@web50607.mail.re2.yahoo.com> Message-ID: On Wed, 22 Aug 2007 08:17:36 -0700 (PDT), Jeff Caldwell wrote: > LWL 5.0.x Personal Edition does not exhibit the problem. Ah, OK, so that's an interesting tidbit. /Maybe/ LW 4.x is not "64-bit clean" (whatever that means). But it could be a bug in flexi streams as well... > I suppose the limitation of my workaround (write-string vs > write-sequence) is the charset, no UTF? Not with flexi streams. > Anything else to be aware of? No, I'm lost. It'd be cool if you could boil it down to a simple test case to send to LW support. But, OTOH, if it's only a 4.x issue, they probably don't care much. > Maybe I can leverage this app into a nice new 5.0 license, courtesy > of my employer. Hehe... :) > If not, do you have a quick thought regarding where else I might > look to change the behavior in 4.3.7? No, unfortunately not.