From: Arseny S. <am...@in...> - 2003-03-29 22:39:28
|
Hello Sam, Friday, March 28, 2003, 12:55:59 AM, you wrote: >> How back_trace get augmented ? > see unwind_back_trace() and with_saved_back_trace() in src/lispbibl.d > 1. compile with g++ & define DEBUG_SPVW. this will enable a back_trace > check whenever it is modified (see p_backtrace_t in src/lispbibl.d). > 2. Add this to back_trace_check() in src/spvw_debug.d: > for (int index=0; bt; bt=bt->bt_next, index++) > if (!functionp(bt->bt_caller)) { > fprintf(stderr,"\n%s:%d:%s: non-function caller at %d\n", > file,line,label,index); > back_trace_out(stderr,bt); > abort(); > } functionp doesn't suit this case - it is false for records of type Fsubr and Closure whatever they might be. Anyway, I made such test function and discovered that bt_caller of second element of backtrace list seems to be changed during execution of with_saved_back_trace. I.e. invalid elements are not inserted in back_trace list, they are produced by changing the list elements, not the top ones (the ones that become top after with_saved_back_trace execution). This happens particularly with following line in eval.d (function eval_subr) # SUBR without &REST-Flag: apply_subr_norest: with_saved_back_trace(fun,-1,(*(subr_norest_function_t*)(TheSubr(fun)->function))()); fun is (gdb) p object_out(fun) #<SYSTEM-FUNCTION MACRO-FUNCTION> I wasn't able yet to list all function names being passed to eval_subr which cause this effect - [n]object_out both report error on some of them. I wonder whether it may be related to intent back_trace list hacking or to reusing of pointed areas (are all of backtrace_t structs found in the stack ?). Or is it GC ? Change happens only after GC. -- Best regards, Arseny mailto:am...@in... |