Opened 2 years ago

Closed 2 years ago

#439 closed defect (fixed)

Quicklisp RFC2388 case of no meaningful error

Reported by: Evenson Not Org Owned by:
Priority: major Milestone: 1.5.0
Component: streams Version: 1.5.0-dev
Keywords: quicklisp-rfc2388 debugger ansi Cc:
Parent Tickets:

Description

For the code

(ql:quickload :rfc2388)
(RFC2388:PARSE-HEADER "multipart/form-data; boundary=------------------------ea3255a8d6193fb7" :VALUE)

there is surprisingly no error returned to SLIME.

Running ABCL from the command line returns the following trace

java.lang.StringIndexOutOfBoundsException: String index out of range: 19
	at java.lang.StringBuffer.setCharAt(StringBuffer.java:255)
	at org.armedbear.lisp.SeekableStringWriter.write(SeekableStringWriter.java:87)
	at org.armedbear.lisp.Stream._writeChar(Stream.java:1860)
	at org.armedbear.lisp.Stream$3.execute(Stream.java:2106)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:814)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:832)
	at org.armedbear.lisp.pprint_159.execute(pprint.lisp:769)
	at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:814)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:832)
	at org.armedbear.lisp.rfc2388_tmp4O4DY0LA_16.execute(rfc2388.lisp:225)
	at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:832)
	at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:814)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:832)
	at org.armedbear.lisp.rfc2388_tmp4O4DY0LA_15.execute(rfc2388.lisp:225)
	at org.armedbear.lisp.clos_306.execute(clos.lisp:2720)
	at org.armedbear.lisp.clos_280.execute(clos.lisp:2302)
	at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109)
	at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:814)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:832)
	at org.armedbear.lisp.rfc2388_tmp4O4DY0LA_14.execute(rfc2388.lisp:220)
	at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:832)
	at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:814)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:832)
	at org.armedbear.lisp.rfc2388_tmp4O4DY0LA_13.execute(rfc2388.lisp:220)
	at org.armedbear.lisp.clos_306.execute(clos.lisp:2720)
	at org.armedbear.lisp.clos_280.execute(clos.lisp:2302)
	at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109)
	at org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:109)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:832)
	at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582)
	at org.armedbear.lisp.Lisp.eval(Lisp.java:540)
	at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:814)
	at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575)
	at org.armedbear.lisp.Lisp.eval(Lisp.java:540)
	at org.armedbear.lisp.Lisp.progn(Lisp.java:709)
	at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742)
	at org.armedbear.lisp.Lisp.eval(Lisp.java:530)
	at org.armedbear.lisp.Lisp.progn(Lisp.java:709)
	at org.armedbear.lisp.Closure.execute(Closure.java:220)
	at org.armedbear.lisp.Closure.execute(Closure.java:148)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:814)
	at org.armedbear.lisp.Lisp$1.execute(Lisp.java:285)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:803)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:814)
	at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407)
	at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89)
	at org.armedbear.lisp.Symbol.execute(Symbol.java:793)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:798)
	at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415)
	at org.armedbear.lisp.LispThread.execute(LispThread.java:798)
	at org.armedbear.lisp.Interpreter.run(Interpreter.java:361)
	at org.armedbear.lisp.Main$1.run(Main.java:48)
	at java.lang.Thread.run(Thread.java:745)
#<THREAD "interpreter" {2B376972}>: Debugger invoked on condition of type ERROR
  Caught java.lang.StringIndexOutOfBoundsException: String index out of range: 19.

Two problems:

1) Why does SLIME not catch this error?

2) Figuring out what is the problem with the underlying code

Subtickets

Change History (2)

comment:1 Changed 2 years ago by Evenson Not Org

Answer to question 1) ("Why does SLIME not catch this error?"): because SeekableStringWriter? "swallows" the Java runtime exception rather than converting into a JavaExeception? type.

Patch like this

diff -r 250b651f6d84 src/org/armedbear/lisp/SeekableStringWriter.java
--- a/src/org/armedbear/lisp/SeekableStringWriter.java	Thu Feb 02 09:23:00 2017 +0000
+++ b/src/org/armedbear/lisp/SeekableStringWriter.java	Fri Feb 03 08:08:27 2017 +0100
@@ -36,6 +36,7 @@
 import static org.armedbear.lisp.Lisp.*;
 
 import java.io.Writer;
+import java.text.MessageFormat;
 
 public final class SeekableStringWriter extends Writer {
     private final StringBuffer stringBuffer;
@@ -81,11 +82,15 @@
 
     @Override
     public void write(int c) {
+      try {
         if (offset == stringBuffer.length())
             stringBuffer.append((char) c);
         else
             stringBuffer.setCharAt(offset, (char) c);
         ++offset;
+      } catch (IndexOutOfBoundsException e) {
+        error(new JavaException(e));
+      }
     }
 
     @Override
Last edited 2 years ago by Evenson Not Org (previous) (diff)

comment:2 Changed 2 years ago by Evenson Not Org

Component: otherstreams
Keywords: ansi added
Resolution: fixed
Status: newclosed

As to "Figuring out what is the problem with the underlying code" the problem was that CL:GET-OUTPUT-STREAM-STRING was not resetting the underlying string buffer on reads.

This has been fixed with <http://abcl.org/trac/changeset/14976>.

Note: See TracTickets for help on using tickets.