Thread: [Clg-devel] error recovery
Brought to you by:
espen
From: Hazen B. <hba...@ma...> - 2007-03-02 03:57:41
|
Hello, Is there way to recover from an error that throws you into the slime debugger? It seems that when this happens to me the only way to recover is to restart my lisp process. Attempting to rerun a gtk program is unsuccessful and I get the following backtrace: memory fault [Condition of type SB-KERNEL::MEMORY-FAULT-ERROR] Restarts: 0: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (SB-KERNEL::MEMORY-FAULT-ERROR) 1: ("foreign function: call_into_lisp") 2: ("foreign function: post_signal_tramp") 3: ("foreign function: g_signal_emit_valist") 4: ("foreign function: g_signal_emit") 5: ("foreign function: #xB7901F2F") 6: ("foreign function: #xB78FE75F") 7: ("foreign function: g_object_set_property") SBCL 0.9.16, gtk-2.8.16, cvs clg. thanks, -Hazen |
From: Espen S J. <es...@cs...> - 2007-03-12 14:45:11
|
Hazen Babcock <hba...@ma...> writes: > Is there way to recover from an error that throws you into the slime > debugger? It seems that when this happens to me the only way to > recover is to restart my lisp process. Attempting to rerun a gtk > program is unsuccessful and I get the following backtrace: If you mean recover form an error in foreign code, then the general answer would be no. Sometimes you may actually be able to abort to the toplevel, but the system could be left in an inconsistent state which may cause mysterious subsequent crashes. The reason for this is the lack of anything similar unwind-protect in C. If an error occurs in a signal handler, you should choose one of the custom restarts for signal handlers, and never abort to the toplevel directly. -- Espen |