good evening; On 2010-04-12, at 17:25 , Erik Huelsmann wrote:
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?
it was not consuming inordinate amounts of cpu, just not doing anything useful.
"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?
i don't know. it's not my code. it one of the projects from the clbuild repertory which abcl trips over in the course of an exhaustive build.