Hi James,
On Mon, Apr 12, 2010 at 1:56 PM, james anderson james.anderson@setf.de wrote:
good afternoon;
attached below is the transcript of an aborted build of cl-pdf. abcl hangs when it attempts to compile pdf-geom.lisp.
is the cause clear from the stack?
Possibly. Is ABCL busy looping at the moment you kill it? I.e. is it consuming (lots of) CPU?
"DestroyJavaVM" prio=10 tid=0x08e7e000 nid=0x22f2 waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE
"interpreter" prio=10 tid=0x08f2d000 nid=0x22fa runnable [0xb4413000] java.lang.Thread.State: RUNNABLE at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:77) at sun.nio.cs.UTF_8$Decoder.xflow(UTF_8.java:183) at sun.nio.cs.UTF_8$Decoder.decodeArrayLoop(UTF_8.java:242) at sun.nio.cs.UTF_8$Decoder.decodeLoop(UTF_8.java:324) at java.nio.charset.CharsetDecoder.decode (CharsetDecoder.java:561) at org.armedbear.lisp.util.RandomAccessCharacterFile.read (RandomAccessCharacterFile.java:375) at org.armedbear.lisp.util.RandomAccessCharacterFile $RandomAccessReader.read(RandomAccessCharacterFile.java:224) at org.armedbear.lisp.util.RandomAccessCharacterFile $RandomAccessReader.read(RandomAccessCharacterFile.java:190) at org.armedbear.lisp.Stream._readChar(Stream.java:1684)
This bit of the stacktrace would suggest there's a problem decoding the UTF-8 in the file it's trying to read. Could it be that it contains non-UTF-8 characters? If so, these should be replaced by ABCL with replacement characters, but we have seen ABCL bugs in the past where it was incorrectly looping in such cases.
Is this such a case?
Bye,
Erik.