Robert Goldman wrote on Wed, Nov 28, 2012 at 09:54:23PM -0600:
> I have a set of unit tests, written in FiveAM, that invokes code that
> calls (sb-ext:gc :full t) and from there, dumps into the ldb:
> fatal error encountered in SBCL pid 61162:
> no transport function for object 0x043a191f (widetag 0x93)
This usually happens when there is memory corruption. Could be bad C
code, fast-mode Lisp code with type errors or bad hardware.
If there is any Lisp code not running at max safety you should turn it
to max and re-run. This gets most of ours.
Otherwise, in the past I tracked some of those gems by increasing the
GC frequency, so that the time between corrupting things and detecting
the corruption is reduced. It's also good to look at the object in
the heap before your corrupted object since there is a good chance it
has originally been allocated by the same piece of work code.
> Error opening /dev/tty: Device not configured
> Welcome to LDB, a low-level debugger for the Lisp runtime environment.
> ldb> backtrace
> 0: Foreign function ldb_monitor, fp = 0x19fcc30, ra = 0x1081c6
> 1: Foreign function call_lossage_handler, fp = 0x19fcc40, ra = 0x10545a
> 2: Foreign function lose, fp = 0x19fcd30, ra = 0x1056a1
> 3: Foreign function trans_lose, fp = 0x19fcd40, ra = 0x1037a3
> 4: Foreign function scav_other_pointer, fp = 0x19fcd70, ra = 0x10337e
> 5: Foreign function scavenge, fp = 0x19fcdc0, ra = 0x10499b
> 6: Foreign function scav_instance, fp = 0x19fcde0, ra = 0x1035d4
> 7: Foreign function scavenge, fp = 0x19fce30, ra = 0x10499b
> 8: Foreign function scavenge_newspace_generation_one_scan, fp =
> 0x19fce60, ra = 0x1116a4
> 9: Foreign function collect_garbage, fp = 0x19fced0, ra = 0x112894
> 10: SB-KERNEL::COLLECT-GARBAGE
> 11: (COMMON-LISP::FLET SB-THREAD::WITH-MUTEX-THUNK KEYWORD::IN
> 12: (COMMON-LISP::FLET SB-THREAD::EXEC KEYWORD::IN SB-KERNEL::SUB-GC)
> 13: (COMMON-LISP::FLET WITHOUT-INTERRUPTS-BODY-41 KEYWORD::IN
> 14: SB-KERNEL::SUB-GC
> 15: SB-EXT::GC
> 16: COMMON-LISP-USER::CIRCA-GC
> This is on MacOS X Lion, most recently on a copy of SBCL I pulled from
> git today (I pulled and rebuilt to make sure I wasn't seeing a
> previously fixed bug).
> Is there something I can do to help diagnose this? Information I should
> be collecting?
> Is there anything bad my code could be doing to cause this?
> Keep yourself connected to Go Parallel:
> VERIFY Test and improve your parallel project with help from experts
> and peers. http://goparallel.sourceforge.net
> Sbcl-devel mailing list
Martin Cracauer <cracauer@...> http://www.cons.org/cracauer/