From: Sam S. <sd...@gn...> - 2004-11-25 17:34:36
|
> * Bruno Haible <oe...@py...t> [2004-11-24 22:25:06 +0100]: > > - Your <NN> output lines, generated through the backtrace pointers, > are misplaced. (The <11> line should be one line below.) Probably > you compare the STACK / FRAME pointers incorrectly. Can you fix > that, please? Does this patch fix the problem? --- debug.d 25 Nov 2004 11:47:15 -0500 1.77 +++ debug.d 25 Nov 2004 12:31:22 -0500 @@ -1462,16 +1462,16 @@ var p_backtrace_t bt = back_trace; while (!eq(FRAME_(0),nullobj) /* nullobj = stack end */ && (frame_limit==0 || count<frame_limit)) { - while (bt_beyond_stack_p(bt,FRAME)) { - print_back_trace(stream_,bt,++count); - bt = bt->bt_next; - } if (frame_up_x != NULL) { var gcv_object_t* next_frame = (*frame_up_x)(FRAME); if (next_frame == FRAME) break; print_stackitem(stream_,FRAME = next_frame); } else FRAME = print_stackitem(stream_,FRAME); + while (bt_beyond_stack_p(bt,FRAME)) { + print_back_trace(stream_,bt,++count); + bt = bt->bt_next; + } } skipSTACK(1); /* drop *STANDARD-OUTPUT* */ return count; > And about the crash: My simple guess is that some of the many uintL > (32-bit) variables in spvw*.d are not sufficient when the total heap > is bigger than 4 GB. Fortunately, this is easier to fix than to make > the fixnums 48-bit. Can you confirm, Sam, that allowing a heap bigger > than 4 GB is higher priority than having 48-bit fixnums? of course! 48-bit fixnums (actually, 56-bit fixnums, but who's counting? :-) are a critical efficiency issue, while 4GB heap limit is a showstopper. Thanks! -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> A professor is someone who talks in someone else's sleep. |