abrt version: 1.1.18 architecture: x86_64 Attached file: backtrace, 236277 bytes cmdline: /usr/lib/gcl-2.6.8/unixport/saved_ansi_gcl -dir /usr/lib/gcl-2.6.8/unixport/ -libdir /usr/lib/gcl-2.6.8/ -eval '(setq si::*allow-gzipped-file* t)' -eval '(setq si::*tk-library* \"/usr/lib64/tk8.5\")' -load Miklee-em.lisp comment: Unfortunately, I was working interactively and not sure what I did, precisely :-( component: gcl Attached file: coredump, 187203584 bytes crash_function: error executable: /usr/lib/gcl-2.6.8/unixport/saved_ansi_gcl kernel: 2.6.35.14-95.fc14.x86_64 package: gcl-2.6.8-0.8.20110516cvs.fc14 rating: 4 reason: Process /usr/lib/gcl-2.6.8/unixport/saved_ansi_gcl was killed by signal 6 (SIGABRT) release: Fedora release 14 (Laughlin) How to reproduce: Probably my fault (in a way) in attempting to define a badly-written DEFMETHOD PRINT-OBJECT … but, I don't think it should have crashed, just errored out? time: 1315094299 uid: 500
Created attachment 521352 [details] File: backtrace
From the backtrace, it looks like formatted output was being produced when a type error was encountered (frame 483). The active error handler tried to print some objects (presumably for an error message), apparently including the one whose PRINT-OBJECT method included the type error, which triggered the same type error again (frame 442). The active error handler tried to print some objects .... ... and so on until stack space was exhausted, at which point GCL aborted. I'm not at all sure this is a GCL bug. What could GCL have done differently?
I'm 99% sure this is a bug in the reporter's code, not GCL, and have not heard back from the reporter, so I'm closing this bug.