From: IPmonger <ipm...@de...> - 2002-03-08 07:44:44
|
Sam Steingold <sd...@gn...> writes: > add -DDEBUG_EVAL -DDEBUG_SPVW to CFLAGS. Ok, so I did this and it fails to compile spvw.c because of problems in spvw_general.d: spvw_genera1.d:948: structure has no member named `heapnr_from_type' spvw_genera1.d:953: structure has no member named `heapnr_from_type' spvw_genera1.d:962: `symbol_type' undeclared (first use in this function) These are caused by the -DDEBUG_SPVW flag. the heapnr_from_type member of the mem struct is only present if the following are true (spvw_global.d, lines 44-54): #if defined(SPVW_MIXED_BLOCKS) && defined(TYPECODES) && defined(GENERATIONAL_GC) sintB heapnr_from_type[typecount]; # Tabelle type -> heapnr #endif #if defined(SPVW_MIXED_BLOCKS_OPPOSITE) && !defined(TRIVIALMAP_MEMORY) # now empty, free for Lisp objects. #define MEMRES conses.heap_end # now the emergency reserve # Upper limit of big allocated memory block. aint MEMTOP; #endif GENERATIONAL_GC, SPVW_MIXED_BLOCKS, SPVW_MIXED_BLOCKS_OPPOSITE and TRIVIALMAP_MEMORY are all defined, but TYPECODES are not - NO_TYPECODES are instead. So, there is a bug here in spvw_genera1.d, lines 945-957, as not all SPVW_MIXED are the same. #ifdef SPVW_PURE heap = &mem.heaps[type]; #else # SPVW_MIXED heap = &mem.heaps[mem.heapnr_from_type[type]]; #endif if ((addr >= heap->heap_gen0_start) && (addr < heap->heap_gen0_end)) return false; #ifdef SPVW_MIXED_BLOCKS_OPPOSITE if (is_cons_heap(mem.heapnr_from_type[type])) { if ((addr >= heap->heap_start) && (addr < heap->heap_gen1_end)) return true; # Pointer in die neue Generation } else #endif I don't know enough about what's going on to even offer a suggestion as to how to fix it, though. :-( The error about symbol_type is due to the fact that TYPECODES is not defined. > I use the exact same distribution and kernel here and I do not > observe this. is it possible that you have some weird configuration > issue (like some libraries were compiled with gcc3 and other with gcc > 2.96)? I don't think so because I personally never use gcc3. However, I have run the RedHat up2date facility and *they* might have done that. > is the crash totally predictable (I mean the place & time, not > CRASH-P)? yes. > if yes and you can stop in gdb right before the crash reliably, try > (gdb) p gar_col() > > after pushSTACK(object1); but before allocate_cons(); and see is the > crash goes away or happens inside GC. > > also, do > (gdb) p object_out(object1) > and > (gdb) p STACK_0 (and STACK_1)... I'll try these as well, once I get it to compile with the debugging statements you've suggested above that seem to be causing problems. -IPmonger -- ------------------ IPmonger ipm...@de... CCIE #8338 |