[armedbear-devel] abcl hangs when building cl-pdf component pdf-geom.lisp

[Erik Huelsmann]

Hi James,

On Mon, Apr 12, 2010 at 1:56 PM, james anderson <james.anderson at 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.