Question

我正在使用正确执行的包drakma：

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

单独使用时。但是一旦我开始使用我自己编写的包，就会导致控件堆栈溢出。回溯看起来像这样：

...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))

大约有15k个打印对象相互调用。

我发现错误在这三行中：

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

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

wheras (rstyl:LOG-ERROR err)是一个扩展为：

的宏

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

*LOG-STREAM-ERROR*的值为：#<SYNONYM-STREAM :SYMBOL SB-SYS:*TTY* {10001B3103}> 这条线怎么会有这么大的影响？

Answer 1

实际上很少有东西。

simple-error是一种定义用于打印它的特殊插槽的条件，:format-control和:format-arguments。不幸的是，它们具有很小的实用性，因为你既不能在子条件的定义中也不能在任何后初始化钩子中覆盖它们，因为它们都没有。一般来说，我发现simple-error的用处非常有限，因为它不能只捕获打印所需的消息，而是每次创建此条件的实例时都必须提供消息。

因此，如果您想扩展simple-error，您可以执行以下操作：

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

然后，您的日志记录可能如下所示：

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

它会打印"Erroneous recepie action happened"消息。不是很糟糕，但你没有使用唯一的功能区分这个条件和它的祖先，condition条件，即它打印格式化输出的能力。

换句话说，我并没有真正看到你的情况扩展simple-error我认为它主要是根据你在构建它时提供的论据来促进报告的功能，但如果你不赞成不给任何东西，那就浪费了。

无休止的递归SB-KERNEL：OUTPUT-OBJECT

1 个答案: