From: Arseny S. <am...@in...> - 2003-03-25 09:57:07
|
Hi, I tried, as Sam suggested, increase the stack size to avoid signal 11 (SIGSEGV) at the stage of loading compiler.lisp. As ulimit -s is 2046 and cannot be changed (?) I did as cygwin FAQ suggests - used gcc option -Wl,--stack,8192. Unfortunately ld help doesn't answer whether the size should be in bytes or kbytes or whatelse. My guess this is bytes since values under about 8192 do not affect executable behaviour. Values of 8192 - ~1500000 lead to silent quit with error 128 when clisp tries to load "init.lisp". Values above 1500000 make clisp behave as in default case - make SIGSEGV in the same place (same under gdb - I don't know how it is without gdb) - in the gc_mark. All this with g++. More precisely error occurs at line 291 (for me - I changed the file to dump some info). This is the session (vobj is Record_type(dies)). Any thoughts ? ;; Loading file /cygdrive/d/clisp-cvs/cygwclisp/build-cy++/compiler.lisp ... Program received signal SIGSEGV, Segmentation fault. 0x0040466d in _Z7gc_mark6object (obj={one_o = 269830741, allocstamp = 80946}) at spvw_garcol.d:291 291 switch (Record_type(dies)) { (gdb) print dies $1 = {one_o = 1936269413, allocstamp = 80946} (gdb) print vobj $2 = 0x10154a54 (gdb) print *vobj $3 = {GCself = {one_o = 2417607661}, tfl = 2417314392, recdata = 0x10154a5c} (gdb) print obj $4 = {one_o = 269830741, allocstamp = 80946} (gdb) up #1 0x00406fa0 in _Z14gar_col_normalv () at spvw_garcol.d:1817 1817 for (; bt; bt = bt->bt_next) gc_mark(bt->bt_caller); (gdb) up #2 0x0040b0b7 in _Z17do_gar_col_simplev () at spvw_garcol.d:2551 2551 gar_col_normal(); -- Best regards, Arseny mailto:am...@in... |
From: Sam S. <sd...@gn...> - 2003-03-25 20:16:30
|
> * In message <130...@in...> > * On the subject of "cygwin build - signal 11" > * Sent on Tue, 25 Mar 2003 19:59:53 +1000 > * Honorable Arseny Slobodjuck <am...@in...> writes: > > I tried, as Sam suggested, increase the stack size to avoid signal > 11 (SIGSEGV) at the stage of loading compiler.lisp. As ulimit -s is > 2046 and cannot be changed (?) I did as cygwin FAQ suggests - used > gcc option -Wl,--stack,8192. Unfortunately ld help doesn't answer > whether the size should be in bytes or kbytes or whatelse. My guess > this is bytes since values under about 8192 do not affect executable > behaviour. Values of 8192 - ~1500000 lead to silent quit with error > 128 when clisp tries to load "init.lisp". Values above 1500000 make > clisp behave as in default case - make SIGSEGV in the same place > (same under gdb - I don't know how it is without gdb) - in the > gc_mark. All this with g++. do you observe any difference between g++ and gcc? > ;; Loading file /cygdrive/d/clisp-cvs/cygwclisp/build-cy++/compiler.lisp ... > Program received signal SIGSEGV, Segmentation fault. > 0x0040466d in _Z7gc_mark6object (obj={one_o = 269830741, allocstamp = 80946}) > at spvw_garcol.d:291 > 291 switch (Record_type(dies)) { > (gdb) print dies > $1 = {one_o = 1936269413, allocstamp = 80946} > (gdb) print vobj > $2 = 0x10154a54 > (gdb) print *vobj > $3 = {GCself = {one_o = 2417607661}, tfl = 2417314392, recdata = 0x10154a5c} > (gdb) print obj > $4 = {one_o = 269830741, allocstamp = 80946} > (gdb) up > #1 0x00406fa0 in _Z14gar_col_normalv () at spvw_garcol.d:1817 > 1817 for (; bt; bt = bt->bt_next) gc_mark(bt->bt_caller); > (gdb) up > #2 0x0040b0b7 in _Z17do_gar_col_simplev () at spvw_garcol.d:2551 > 2551 gar_col_normal(); so the bad guy is in backtrace! what does Record_type_(obj) say? also, please try "zbacktrace" in gdb (will probably fail...) -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Only a fool has no doubts. |
From: Arseny S. <am...@in...> - 2003-03-25 23:41:59
|
Hello Sam, Wednesday, March 26, 2003, 6:17:34 AM, you wrote: >> I tried, as Sam suggested, increase the stack size to avoid signal >> 11 (SIGSEGV) at the stage of loading compiler.lisp. As ulimit -s is >> 2046 and cannot be changed (?) I did as cygwin FAQ suggests - used >> gcc option -Wl,--stack,8192. Unfortunately ld help doesn't answer >> whether the size should be in bytes or kbytes or whatelse. My guess >> this is bytes since values under about 8192 do not affect executable >> behaviour. Values of 8192 - ~1500000 lead to silent quit with error >> 128 when clisp tries to load "init.lisp". Values above 1500000 make >> clisp behave as in default case - make SIGSEGV in the same place >> (same under gdb - I don't know how it is without gdb) - in the >> gc_mark. All this with g++. > do you observe any difference between g++ and gcc? SIGSEGV occurs at the same line but objects I dump slightly differ. >> 291 switch (Record_type(dies)) { > so the bad guy is in backtrace! Hmmm > what does Record_type_(obj) say? Record_type_ ? Record_type's before sigsegv are 28,28,28... then (in gcc) 0 then one of 51/54/58 and then sigsegv. There is one thing I can't explain: even at the first interation dies not always has the same one_o as obj. At the beginning of gc_mark: var object dies = obj; /* current object */ Just after this line as_oint(obj) is always equal to as_oint(dies). Before the switch they aren't always equal. Something like this (first line - printf after the assignment, second - before the switch): gc_mark obj = 0x59942a dies = 0x59942a vAROBJ bias: obj = 59942a dies = 59e351 here come further iterations where dies != obj, it's ok Am I overlooking something ? > also, please try "zbacktrace" in gdb (will probably fail...) Undefined command. -- Best regards, Arseny mailto:am...@in... |
From: Sam S. <sd...@gn...> - 2003-03-26 01:58:23
|
> * In message <186...@in...> > * On the subject of "Re[2]: cygwin build - signal 11" > * Sent on Wed, 26 Mar 2003 09:45:50 +1000 > * Honorable Arseny Slobodjuck <am...@in...> writes: > > > so the bad guy is in backtrace! > Hmmm > > what does Record_type_(obj) say? > Record_type_ ? a function in spvw_debug.d > Record_type's before sigsegv are 28,28,28... then > (in gcc) 0 then one of 51/54/58 and then sigsegv. look at the Rectype_* enum - what are these types? (make lispbibl.h is your friend) > Am I overlooking something ? you are looking at the place after the bug. we have to find where back_trace->bt_caller becomes invalid, i.e., not a Subr/Fsubr/Closure. > > also, please try "zbacktrace" in gdb (will probably fail...) > Undefined command. look at spvw_debug.d and .gdbinit for inspiration. g++ allows tracking all back_trace manipulations, see p_backtrace_t in lispbibl.d, you may want to enchance it to check all bt_caller fields for being Subr/Fsubr/Closure. -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Good programmers treat Microsoft products as damage and route around it. |
From: Arseny S. <am...@in...> - 2003-03-27 13:13:55
|
Hello Sam, Wednesday, March 26, 2003, 11:59:27 AM, you wrote: >> Record_type's before sigsegv are 28,28,28... then >> (in gcc) 0 then one of 51/54/58 and then sigsegv. > look at the Rectype_* enum - what are these types? > (make lispbibl.h is your friend) >> Am I overlooking something ? I did. > you are looking at the place after the bug. > we have to find where back_trace->bt_caller becomes invalid, i.e., not > a Subr/Fsubr/Closure. >> > also, please try "zbacktrace" in gdb (will probably fail...) >> Undefined command. p back_trace_out(0,0) causes another SIGSEGV > look at spvw_debug.d and .gdbinit for inspiration. > g++ allows tracking all back_trace manipulations, see p_backtrace_t in > lispbibl.d, you may want to enchance it to check all bt_caller fields > for being Subr/Fsubr/Closure. That's what I got with the following code var p_backtrace_t bt = back_trace; for (; bt; bt = bt->bt_next) { int rectype = -1; char * sbias = "??"; switch (as_oint(object(bt->bt_caller)) & nonimmediate_bias_mask) { case cons_bias: sbias = "cons";break; case varobject_bias: rectype = Record_type(object(bt->bt_caller)); sbias = "rec";break; case subr_bias: sbias = "subr";break; case machine_bias: sbias = "mach";break; default: sbias = "unkn";break; } printf("BT %s %x %x %d\n",sbias,bt,bt->bt_caller,rectype); gc_mark(bt->bt_caller); } ;; Loading file defseq.lisp ... ;; Loaded file defseq.lisp ;; Loading file backquote.lisp ... ;; Loaded file backquote.lisp ;; Loading file defmacro.lisp ...BT subr 1061e20 6fe4e2 -1 BT rec 1062560 1768af9 40 BT rec 10628a0 1768db5 40 BT rec 1062c00 1768c61 40 BT rec 1062fb0 1768c75 40 BT rec 10632f0 1768c25 40 BT rec 10636c0 1768b5d 40 ..... BT rec 108d7e0 1768d51 40 BT rec 108dc40 1768c89 40 BT rec 108e000 1768b71 40 BT rec 108e750 179bf9d -4 BT subr 108ef60 6fe64a -1 BT subr 108f6c0 6fe632 -1 BT subr 108f910 6fe4b2 -1 ;; Loaded file defmacro.lisp I.e. most of bt_callers are records of Rectype_Fsubr, also there are Rectype_Closure's and subr's. Before the crash: ;; Loading file /cygdrive/d/clisp-cvs/cygwclisp/build-cy++/compiler.lisp ...BT subr 107d660 6ff7ea -1 BT rec 107e4b0 17ee7e1 40 BT rec 107e800 17ee77d 40 BT rec 107eb40 17ee665 40 BT rec 107eec0 17ee7e1 40 BT rec 107f340 17ee7f5 40 BT rec 107f710 17ee6a1 40 ... BT rec 108c430 17ee7a5 40 BT rec 108c780 17ee81d 40 BT rec 108caf0 17ee63d 40 BT rec 108cec0 17ee6a1 40 BT rec 108d340 17ee7f5 40 BT rec 108d7e0 17ee895 40 BT rec 108dc40 17ee7cd 40 BT rec 108e000 17ee6b5 40 BT rec 108e750 18cb675 96 Bad rectype Program received signal SIGFPE, Arithmetic exception. This is my check in gc_mark. Rectype of >=53 is erroneous. Without the gdb error occurs earlier: ;; Loading file places.lisp ...BT subr 108a8a0 6fecc2 -1 BT subr 108ad70 6fecc2 -1 BT subr 108b240 6fecc2 -1 BT subr 108b710 6fecc2 -1 BT subr 108bbe0 6fecc2 -1 BT subr 108c0b0 6fecc2 -1 BT subr 108c590 6fef92 -1 BT rec 108cd30 177962d 40 BT rec 108d1b0 1779781 40 BT rec 108d650 1779821 40 BT rec 108dab0 1779759 40 BT rec 108de70 1779641 40 BT rec 108e5c0 1799ac1 -4 BT subr 108edd0 6fe64a -1 BT rec 108f4e0 1764689 -115 Signal 11 make: *** [interpreted.mem] Error 139 How back_trace get augmented ? -- Best regards, Arseny mailto:am...@in... |
From: Sam S. <sd...@gn...> - 2003-03-27 14:54:51
|
> * In message <128...@in...> > * On the subject of "Re[4]: cygwin build - signal 11" > * Sent on Thu, 27 Mar 2003 22:46:51 +1000 > * Honorable Arseny Slobodjuck <am...@in...> writes: > > 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(); } -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Old Age Comes at a Bad Time. |
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... |
From: Sam S. <sd...@gn...> - 2003-03-30 01:04:24
|
> * In message <723...@in...> > * On the subject of "Re[6]: cygwin build - signal 11" > * Sent on Sun, 30 Mar 2003 08:43:40 +1000 > * Honorable Arseny Slobodjuck <am...@in...> writes: > > (are all of backtrace_t structs found in the stack ?). yes. > Or is it GC ? Change happens only after GC. I just fixed some problems with GC/back_trace. I might be that the problem we are talking about is now gone. please cvs up. -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Are you smart enough to use Lisp? |
From: Arseny S. <am...@in...> - 2003-03-30 02:24:38
|
Hello Sam, Sunday, March 30, 2003, 11:05:32 AM, you wrote: >> (are all of backtrace_t structs found in the stack ?). > yes. >> Or is it GC ? Change happens only after GC. > I just fixed some problems with GC/back_trace. > I might be that the problem we are talking about is now gone. > please cvs up. Wow, they seems gone indeed. -- Best regards, Arseny mailto:am...@in... |
From: Sam S. <sd...@gn...> - 2003-03-30 02:42:55
|
> * In message <185...@in...> > * On the subject of "Re[8]: cygwin build - signal 11" > * Sent on Sun, 30 Mar 2003 12:28:49 +1000 > * Honorable Arseny Slobodjuck <am...@in...> writes: > > > I just fixed some problems with GC/back_trace. > > I might be that the problem we are talking about is now gone. > > please cvs up. > > Wow, they seems gone indeed. Sorry about causing you guys so much grief by my sloppiness! Dan, could you please confirm that the problem is gone? So, what is the status of CLISP on win32? - msvc (5,6,7) - mingw gcc g++ - cygwin gcc g++ what about other platforms? -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> If your VCR is still blinking 12:00, you don't want Linux. |