Question

I am using the package drakma, which properly executes:

(drakma:http-request "http://www.google.de")

When used alone. But as soon as I start using a package I wrote by myself it results in an control-stack overflow.
The backtrace looks like this:

...htmlstuff.....
200
((:DATE . "Sat, 08 Dec 2012 01:00:23 GMT") (:EXPIRES . "-1")
 (:CACHE-CONTROL . "private, max-age=0")
 (:CONTENT-TYPE . "text/html; charset=ISO-8859-1")
 (:SET-COOKIE
  . "PREF=ID=5c4b30f4308d3e16:FF=0:TM=1354928423:LM=1354928423:S=1Z5pCWaGYqp7vYxW; expires=Mon, 08-Dec-2014 01:00:23 GMT; path=/; domain=.google.de,NID=66=QXQcXBWPNkcLtxxp5Hmlb7enfDS_wlNOA5bfxT-GsokTpAH4fulI8zxOIl_3IQQzeIcIodmcWDc0JC80k7-d-kOPznrhCJYACNu-zpp7wpPXypilOyjK2mebDUnUl3Xj; expires=Sun, 09-Jun-2013 01:00:23 GMT; path=/; domain=.google.de; HttpOnly")
 (:P3P
  . "CP=\"This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info.\"")
 (:SERVER . "gws") (:X-XSS-PROTECTION . "1; mode=block")
 (:X-FRAME-OPTIONS . "SAMEORIGIN") (:CONNECTION . "close"))
#<PURI:URI http://www.google.de/>
INFO: Control stack guard page unprotected
Control stack guard page temporarily disabled: proceed with caution

debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread
#<THREAD "main thread" RUNNING {1002978CA3}>:
  Control stack exhausted (no more space for function call frames).
This is probably due to heavily nested or infinitely recursive function
calls, or a tail call that SBCL cannot or has not optimized away.

PROCEED WITH CAUTION.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-KERNEL::CONTROL-STACK-EXHAUSTED-ERROR)
0] 



....way more of those....
15854: ((SB-PCL::FAST-METHOD PRINT-OBJECT (T T))
        #<unavailable argument>
        #<unavailable argument>
#1#        #1=
        #<unavailable argument>)
15855: ((LABELS SB-IMPL::HANDLE-IT :IN SB-KERNEL:OUTPUT-OBJECT)
        #<SYNONYM-STREAM :SYMBOL SB-SYS:*TTY* {10001B3103}>)
15856: ((SB-PCL::FAST-METHOD PRINT-OBJECT (T T))
        #<unavailable argument>
        #<unavailable argument>
#1#        #1=
        #<unavailable argument>)
15857: ((LABELS SB-IMPL::HANDLE-IT :IN SB-KERNEL:OUTPUT-OBJECT)
        #<SYNONYM-STREAM :SYMBOL SB-SYS:*TTY* {10001B3103}>)
15858: ((SB-PCL::FAST-METHOD PRINT-OBJECT (T T))
        #<unavailable argument>
        #<unavailable argument>
#1#        #1=
        #<unavailable argument>)
15859: ((LABELS SB-IMPL::HANDLE-IT :IN SB-KERNEL:OUTPUT-OBJECT)
        #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDOUT* {10001DCB03}>)
15860: #1#(PRIN1 #1= NIL)
15861: (SB-IMPL::REPL-FUN NIL)
15862: ((LAMBDA () :IN SB-IMPL::TOPLEVEL-REPL))
15863: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX
        #<CLOSURE (LAMBDA # :IN SB-IMPL::TOPLEVEL-REPL) {10076F355B}>)
15864: (SB-IMPL::TOPLEVEL-REPL NIL)
15865: (SB-IMPL::TOPLEVEL-INIT)
15866: ((FLET #:WITHOUT-INTERRUPTS-BODY-236911 :IN SAVE-LISP-AND-DIE))
15867: ((LABELS SB-IMPL::RESTART-LISP :IN SAVE-LISP-AND-DIE))

with around 15k print-objects calling each other.

I found the error to be in those three lines:

(define-condition recepie-action-errornous (simple-error) ())

(defmethod print-object (err recepie-action-errornous)
  (rstyl:LOG-ERROR err))

wheras (rstyl:LOG-ERROR err) is a macro expanding to:

(WRITE ERR :ESCAPE NIL :STREAM A-PACKAGE:*LOG-STREAM-ERROR*)

The value of *LOG-STREAM-ERROR* is: #<SYNONYM-STREAM :SYMBOL SB-SYS:*TTY* {10001B3103}>
How can this lines have such an massive effect?

Answer 1

There are few things, actually.

simple-error is a kind of condition that defines special slots for printing it, the :format-control and :format-arguments. Unfortunately, they are of a very little utility, as you can’t override them neither in the definition of a child condition, nor in any post-initialization hook, because there’s none. In general, I find simple-error of a very limited usefulness because it can’t just capture the message it needs to print, instead you have to provide the message every time you create an instance of this condition.

So, if you wanted to extend simple-error, you could do something like the following:

(define-condition recepie-action-errornous (simple-error) ()
  (:report
   (lambda (condition stream)
     (declare (ignore condition))
     (format stream "Erroneous recepie action happened"))))

Then, your logging could look like so:

(write (make-condition 'recepie-action-errornous) :escape nil)

And it would print the "Erroneous recepie action happened" message. Not so bad, but you aren’t using the only feature that distinguish this condition from its ancestor, the condition condition, i.e. its ability to print formatted output.

In other words, I don’t really see a point in your situation in extending simple-error I see it’s primarily function in facilitating reporting based on the arguments you give it when you are constructing it, but if you don’t give any, then it’s a bit of a waste.