[armedbear-devel] encoding bug in Stream.readPreservingWhitespace (classpath)
Hi, Attempting to run ABCL with jamvm (which uses the classpath libraires), I get ,---- | Armed Bear Common Lisp 0.20.0-dev | Java 1.5.0 GNU Classpath | JamVM | Low-level initialization completed in 0.371 seconds. | Exception in thread "interpreter" java.lang.IllegalStateException | at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:163) | at org.armedbear.lisp.util.DecodingReader.unread(DecodingReader.java:168) | at org.armedbear.lisp.util.DecodingReader.unread(DecodingReader.java:156) | at org.armedbear.lisp.Stream._unreadChar(Stream.java:1708) | at org.armedbear.lisp.Stream._readToken(Stream.java:1144) | at org.armedbear.lisp.Stream.readToken(Stream.java:1009) | at org.armedbear.lisp.Stream.processChar(Stream.java:508) | at org.armedbear.lisp.Stream.readList(Stream.java:660) | at org.armedbear.lisp.LispReader$3.execute(LispReader.java:88) | at org.armedbear.lisp.Stream.processChar(Stream.java:505) | at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:484) | at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:492) | at org.armedbear.lisp.Stream.read(Stream.java:430) | at org.armedbear.lisp.Load.loadStream(Load.java:556) | at org.armedbear.lisp.Load.loadFileFromStream(Load.java:522) | at org.armedbear.lisp.Load.loadFileFromStream(Load.java:412) | at org.armedbear.lisp.Load.loadSystemFile(Load.java:337) | at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:159) | at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:93) | at org.armedbear.lisp.Main$1.run(Main.java:48) | at java.lang.Thread.run(Thread.java:745) `---- I see in org.armedbear.lisp.Stream.read() a sequence int n = _readChar(); if (n >= 0) { char c = (char) n; // ### BUG: Codepoint conversion Readtable rt = rta.rt(thread); if (!rt.isWhitespace(c)) _unreadChar(c); } which seems likely to be related to this problem. If I print the offending character in DecodingReader.unread() it looks like a #\space. Any suggestions on how to proceed? -- Eric Marsden
Hi Eric, On Sun, Apr 25, 2010 at 11:15 AM, Eric Marsden <eric.marsden@free.fr> wrote:
Hi,
Attempting to run ABCL with jamvm (which uses the classpath libraires), I get
,---- | Armed Bear Common Lisp 0.20.0-dev | Java 1.5.0 GNU Classpath | JamVM | Low-level initialization completed in 0.371 seconds. | Exception in thread "interpreter" java.lang.IllegalStateException | at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:163) | at org.armedbear.lisp.util.DecodingReader.unread(DecodingReader.java:168) | at org.armedbear.lisp.util.DecodingReader.unread(DecodingReader.java:156) | at org.armedbear.lisp.Stream._unreadChar(Stream.java:1708)
| at java.lang.Thread.run(Thread.java:745) `----
I see in org.armedbear.lisp.Stream.read() a sequence
int n = _readChar(); if (n >= 0) { char c = (char) n; // ### BUG: Codepoint conversion Readtable rt = rta.rt(thread); if (!rt.isWhitespace(c)) _unreadChar(c); }
which seems likely to be related to this problem. If I print the offending character in DecodingReader.unread() it looks like a #\space. Any suggestions on how to proceed?
Do you have any idea if the character you were trying to read is outside of the BMP (a so-called Supplemental character; with a code point > #xFFFF)? If that's the case, then you certainly did hit that bug. I had hoped the issue would be relatively infrequent when I added the comment above. Maybe it is, but if you're hitting it, we seem to have an active requirement to fix it... Bye, Erik.
"eh" == Erik Huelsmann <ehuels@gmail.com> writes:
which seems likely to be related to this problem. If I print the offending character in DecodingReader.unread() it looks like a #\space. Any suggestions on how to proceed?
eh> Do you have any idea if the character you were trying to read is eh> outside of the BMP (a so-called Supplemental character; with a code eh> point > #xFFFF)? If that's the case, then you certainly did hit that eh> bug. The offending character seems to be a #\newline character. From what I've understood from looking at DecodingReader.java, this may be a classpath bug rather than an ABCL bug. -- Eric Marsden
Hi Eric,
The offending character seems to be a #\newline character. From what I've understood from looking at DecodingReader.java, this may be a classpath bug rather than an ABCL bug.
Thanks for getting back about this. Could you confirm this with the Classpath project? If it's an ABCL bug afterall, I'd like to learn about it though. Thanks for taking your time to report! Bye, Erik.
participants (2)
-
Eric Marsden -
Erik Huelsmann