From: SourceForge.net <no...@so...> - 2008-05-08 20:40:42
|
Bugs item #1924513, was opened at 2008-03-24 14:03 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1924513&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: build problems >Status: Pending Resolution: Works For Me Priority: 5 Private: No Submitted By: Vladimir Volovich (vvv2) Assigned to: Sam Steingold (sds) Summary: endianness problem on sparc? Initial Comment: when building clisp-2.44.1 on Sparc Solaris 2.8 using Sun Studio 11 compiler, i get an error: during make, when lisp.run is being run for the first time, it stops with a prompt, and i entered a few statements which seem to indicate that there are endianness problems: ./lisp.run -B . -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 2MW -x "(and (setq custom::*load-paths* (quote (\"/opt/home/vvv/src/clisp/clisp-2.44.1/src/\"))) (load \"/opt/home/vvv/src/clisp/clisp-2.44.1/src/init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)" WARNING: locale: no encoding 646, using ISO-8859-1 WARNING: locale: no encoding 646, using ISO-8859-1 *** - Hash table size 16777216 too large 1. Break> (+ 1 0) 1 1. Break> (+ 1 1) 29360130 1. Break> (+ 2 0) 2 1. Break> (+ 2 1) 29360131 1. Break> ^D [/opt/home/vvv/src/clisp/clisp-2.44.1/src/eval.d:527] reset() found no driver frame (sp=0xffbef9a0-0xffbeb4d0) Exiting on signal 6 Bye. make: *** [interpreted.mem] Abort (core dumped) ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2008-05-08 16:40 Message: Logged In: YES user_id=5735 Originator: NO /lisp.run -M interpreted.mem -v -v -v -v -c ../src/compiler.lisp -o ./ will print the stack on error and should enable you to extract the form which produces #<ADDRESS #x00000000> then gdb lisp.run (gdb) interpreted (gdb) break <the function which produces the bad form> (gdb) run type the bad form and see why it is produced. use commands in src/.gdbinit to inspect lisp objects. ---------------------------------------------------------------------- Comment By: Vladimir Volovich (vvv2) Date: 2008-05-08 16:32 Message: Logged In: YES user_id=1804953 Originator: YES yes, it is the same system - sparc solaris 8, with sun studio 11. when building clisp-2.44.1, i am getting those weird problems with (+ 2 1) etc. currently i don't have time to investigate this clisp-2.44.1 build problem. when building clisp-2.45-pre1, there are no problems with (+ 2 1) etc, but the build was failing at compiler.lisp. i added --with-debug, and now it fails like this: ./lisp.run -B . -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 2MW -M interpreted.mem -q -c /opt/home/vvv/src/clisp-pre/clisp-2.45-pre1/src/compiler.lisp -o ./ STACK depth: 262046 [0x399080 0x299208] WARNING: locale: no encoding 646, using ISO-8859-1 ;; Compiling file /opt/home/vvv/src/clisp-pre/clisp-2.45-pre1/src/compiler.lisp ... *** - PRINT: Despite *PRINT-READABLY*, #<ADDRESS #x00000000> cannot be printed readably. 0 errors, 0 warnings make: *** [compiler.fas] Error 1 how could i proceed to debug it further? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2008-05-08 12:25 Message: Logged In: YES user_id=5735 Originator: NO please take a look at unix/PLATFORMS, "Hints for porting to new platforms". please start with "./configure --with-debug -cbc build-g". PS. is this really the same platform which coult not compute (+ 1 2)?! ---------------------------------------------------------------------- Comment By: Vladimir Volovich (vvv2) Date: 2008-05-08 02:16 Message: Logged In: YES user_id=1804953 Originator: YES i tried to build clisp-2.45-pre1, and there are no errors for (+ 2 1) etc., and i get further until compiler.list bets built at which point i get an error: ./lisp.run -B . -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 2MW -M interpreted.mem -q -c /opt/home/vvv/src/clisp-pre/clisp-2.45-pre1/src/compiler.lisp -o ./ WARNING: locale: no encoding 646, using ISO-8859-1 ;; Compiling file /opt/home/vvv/src/clisp-pre/clisp-2.45-pre1/src/compiler.lisp ... *** - handle_fault called at a point inside GC where it shouldn't! *** - handle_fault called at a point inside GC where it shouldn't! *** - handle_fault error6 ! mprotect(0x19dc8000,0x2000,...) -> [/opt/home/vvv/src/clisp-pre/clisp-2.45-pre1/src/spvw_fault.d:189] errno = 0: Error 0. SIGSEGV cannot be cured. Fault address = 0x19dc9f8c. Permanently allocated: 88672 bytes. Currently in use: 7505344 bytes. Free space: 14 bytes. make: *** [compiler.fas] Segmentation Fault (core dumped) make: *** Deleting file `compiler.fas' i looked at the core file: $ dbx ./lisp.run core For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc Reading lisp.run core file header read successfully Reading ld.so.1 Reading libcurses.so.1 Reading libdl.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libmp.so.2 Reading libc_psr.so.1 program terminated by signal SEGV (access to address exceeded protections) 0x0002754c: gc_mark+0x00bc: ld [%l5 + 3], %l2 (dbx) where =>[1] gc_mark(0x19dc9f89, 0x1f, 0x398, 0x7fffffff, 0xfffffffc, 0xfffffff8), at 0x2754c [2] gc_mark_stack(0x2309f8, 0xffbd8c90, 0x0, 0x19dc9f89, 0x40000000, 0x80000000), at 0x2793c [3] gc_markphase(0x7285c0, 0x663aa000, 0x21e291, 0x6673c000, 0x22d400, 0x231878), at 0x27a74 [4] gar_col_normal(0x22c000, 0x663a9d77, 0x0, 0x7285c0, 0x22c058, 0x7), at 0x2beac [5] do_gar_col_simple(0x2d6fc, 0x26410, 0x166d26, 0x22d510, 0x1, 0x59b498), at 0x2d734 [6] gar_col_simple(0x0, 0x0, 0x0, 0x22ec00, 0x2, 0x2d400), at 0x2d764 [7] make_space_gc_true(0x50, 0x22d4cc, 0x22e800, 0xe, 0x22d400, 0x21fed1), at 0x2d994 [8] allocate_s32string(0x12, 0x1, 0xe, 0x22d400, 0x12, 0x22d50c), at 0x2df94 [9] ascii_to_string(0x1f2308, 0x12, 0x0, 0x228800, 0x3fffff, 0x3ffc00), at 0x63f50 [10] quit_on_signal(0x6, 0xfffffffa, 0x216400, 0x1, 0x216400, 0x22ea08), at 0x25d8c [11] sigacthandler(0x6, 0x0, 0xffbd9058, 0xffbd9380, 0x21eb0, 0xfe9b5710), at 0xfea1ab9c ---- called from signal handler with signal 6 (SIGABRT) ------ [12] _kill(0x0, 0x6, 0xffbd9370, 0xffbd9380, 0x21eb0, 0xfe9b5710), at 0xfea1bb54 [13] abort(0xfea38018, 0x663aa000, 0xfffffffc, 0x80000000, 0x663a9ffc, 0x19efc0b1), at 0xfe9b577c [14] gar_col_normal(0x1a009658, 0x1, 0x22d400, 0x7285c0, 0x7, 0xfffff9ff), at 0x2d210 [15] do_gar_col_simple(0x2d6fc, 0x26410, 0x166d26, 0x22d510, 0x1, 0x59b498), at 0x2d734 [16] gar_col_simple(0x14000000, 0x14, 0xfc000000, 0x22ec00, 0x2, 0x2d400), at 0x2d764 [17] make_space_gc_true(0x10, 0x22d4cc, 0x22e800, 0xe, 0x22d400, 0x21fed1), at 0x2d994 [18] allocate_bit_vector(0x22d400, 0x1, 0x3, 0x10, 0x87, 0x22d50c), at 0x2def8 [19] get_closure(0x1, 0x22e800, 0x1, 0x22eb54, 0x21e291, 0x0), at 0x40ae4 [20] C_labels(0x6652ed33, 0x6652ed3b, 0x1a0094d9, 0x22ea08, 0x22eb6c, 0x6652efa3), at 0x59470 [21] eval_fsubr(0x19d0f571, 0x23184c, 0x3, 0x22e800, 0x22ea08, 0xffbd9880), at 0x43b4c [22] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231848, 0x231848), at 0x43050 [23] C_multiple_value_bind(0x0, 0x4, 0x22ea08, 0x231824, 0x6632a58b, 0x2317fc), at 0x5c1f4 [24] eval_fsubr(0x19d0f6f1, 0x2317f8, 0x3, 0x22e800, 0x22ea08, 0xffbd9a48), at 0x43b4c [25] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x2317f0, 0x2317f0), at 0x43050 [26] C_block(0x2317e4, 0x2317e0, 0x22e800, 0x2317e0, 0x21e291, 0x6652eceb), at 0x5a330 [27] eval_fsubr(0x19d0f649, 0x2317cc, 0x3, 0x22e800, 0x22ea08, 0xffbd9dd0), at 0x43b4c [28] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x2317c8, 0x2317c8), at 0x43050 [29] funcall_iclosure(0x231790, 0x231758, 0x22e800, 0x2317b8, 0x21e291, 0x6652ecd3), at 0x425b8 [30] funcall_closure(0x19e2a8f1, 0x216598, 0x4, 0x19e2a8f1, 0xfffffffd, 0x231758), at 0x4beac [31] C_funcall(0x4, 0x231748, 0x6632a91b, 0x22e800, 0x22e800, 0xffbd9ec0), at 0x577b0 [32] eval_subr(0x21772a, 0x1, 0x4, 0x216400, 0x231758, 0x21e291), at 0x44fdc [33] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231744, 0x231744), at 0x43050 [34] funcall_iclosure(0x23170c, 0x2316e0, 0x22e800, 0x231734, 0x21e291, 0x66530783), at 0x425b8 [35] eval_closure(0x19e29ce9, 0x216598, 0x21e291, 0x22ea08, 0x2316e0, 0x2316dc), at 0x4665c [36] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x2316d0, 0x2316d0), at 0x43050 [37] funcall_iclosure(0x231698, 0x23166c, 0x22e800, 0x2316c0, 0x21e291, 0x664fc783), at 0x425b8 [38] eval_closure(0x1a009141, 0x216598, 0x21e291, 0x22ea08, 0x23166c, 0x231668), at 0x4665c [39] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x23165c, 0x23165c), at 0x43050 [40] finish_flet(0x231628, 0x23164c, 0x231644, 0x3, 0x664fc753, 0x22ea08), at 0x59038 [41] eval_fsubr(0x19d0f5a1, 0x23162c, 0x3, 0x22e800, 0x22ea08, 0xffbdab48), at 0x43b4c [42] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231628, 0x231628), at 0x43050 [43] funcall_iclosure(0x2315f0, 0x2315b8, 0x22e800, 0x231618, 0x21e291, 0x664fc73b), at 0x425b8 [44] funcall_closure(0x19e43871, 0x216598, 0x4, 0x19e43871, 0xfffffffd, 0x19), at 0x4beac [45] interpret_bytecode_(0x19e67e71, 0x19e67e50, 0x19e67e62, 0xffbdc1e8, 0x2, 0x22ec00), at 0x4fa98 [46] funcall_closure(0x19e67e71, 0x3, 0x3, 0x19e67e71, 0x19e67e50, 0x4), at 0x4be60 [47] interpret_bytecode_(0x4, 0x19e65ee0, 0x22e800, 0x1, 0x19e66200, 0x19e661ff), at 0x4dd28 [48] funcall_closure(0x19e43949, 0x3, 0x3, 0x19e43949, 0x19e65ee0, 0x4), at 0x4be60 [49] C_funcall(0x3, 0x231594, 0x6632a91b, 0x22e800, 0x22e800, 0xffbdc2c8), at 0x577b0 [50] eval_subr(0x21772a, 0x1, 0x3, 0x216400, 0x2315a0, 0x21e291), at 0x44fdc [51] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231590, 0x231590), at 0x43050 [52] C_multiple_value_bind(0x6653073b, 0x43690, 0x22ea08, 0x231554, 0x23155c, 0x22e800), at 0x5bfd8 [53] eval_fsubr(0x19d0f6f1, 0x231558, 0x3, 0x22e800, 0x22ea08, 0xffbdc7f0), at 0x43b4c [54] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231550, 0x231550), at 0x43050 [55] funcall_iclosure(0x231518, 0x2314e0, 0x22e800, 0x231540, 0x21e291, 0x66530343), at 0x425b8 [56] eval_closure(0x19e29ec9, 0x216598, 0x21e291, 0x22ea08, 0x2314e0, 0x2314dc), at 0x4665c [57] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x2314cc, 0x2314cc), at 0x43050 [58] C_let(0x23149c, 0x7fffffbf, 0x23149c, 0x22ea08, 0x2314a0, 0x21e291), at 0x586c8 [59] eval_fsubr(0x19d0f4e1, 0x2314a0, 0x3, 0x22e800, 0x22ea08, 0xffbdcb78), at 0x43b4c [60] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x23149c, 0x23149c), at 0x43050 [61] C_block(0x231490, 0x23148c, 0x22e800, 0x23148c, 0x21e291, 0x66524293), at 0x5a330 [62] eval_fsubr(0x19d0f649, 0x231478, 0x3, 0x22e800, 0x22ea08, 0xffbdcf00), at 0x43b4c [63] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231474, 0x231474), at 0x43050 [64] funcall_iclosure(0x23143c, 0x231410, 0x22e800, 0x231464, 0x21e291, 0x66524273), at 0x425b8 [65] eval_closure(0x19e311d9, 0x216598, 0x21e291, 0x22ea08, 0x231410, 0x23140c), at 0x4665c [66] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231400, 0x231400), at 0x43050 [67] C_let(0x2313d0, 0x7fffffbf, 0x2313d0, 0x22ea08, 0x2313d4, 0x21e291), at 0x586c8 [68] eval_fsubr(0x19d0f4e1, 0x2313d4, 0x3, 0x22e800, 0x22ea08, 0xffbdd240), at 0x43b4c [69] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x2313d0, 0x2313d0), at 0x43050 [70] C_or(0x66524c03, 0x21e291, 0x3, 0x22e800, 0x4, 0x22efa4), at 0x5e68c [71] eval_fsubr(0x19d0f7c9, 0x2313c0, 0x22eb70, 0x22e800, 0x22ea08, 0xffbdd3d0), at 0x43b4c [72] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x2313c0, 0x2313c0), at 0x43050 [73] C_multiple_value_bind(0x0, 0x2, 0x22ea08, 0x23139c, 0x6632a91b, 0x23138c), at 0x5c1f4 [74] eval_fsubr(0x19d0f6f1, 0x231388, 0x3, 0x22e800, 0x22ea08, 0xffbdd560), at 0x43b4c [75] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231380, 0x231380), at 0x43050 [76] C_let(0x21e291, 0x231370, 0x231350, 0x22ea08, 0x231360, 0x21e291), at 0x58744 [77] eval_fsubr(0x19d0f4e1, 0x231354, 0x3, 0x22e800, 0x22ea08, 0xffbdd680), at 0x43b4c [78] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231350, 0x231350), at 0x43050 [79] eval_fsubr(0x19d0f5d1, 0x21e291, 0x3, 0x22e800, 0x22ea08, 0xffbdd810), at 0x43b4c [80] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231344, 0x231344), at 0x43050 [81] C_let(0x21e291, 0x231334, 0x231314, 0x22ea08, 0x231324, 0x21e291), at 0x58744 [82] eval_fsubr(0x19d0f4e1, 0x231318, 0x3, 0x22e800, 0x22ea08, 0xffbdd9d8), at 0x43b4c [83] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231314, 0x231314), at 0x43050 [84] C_block(0x231308, 0x231304, 0x22e800, 0x231304, 0x21e291, 0x66524b73), at 0x5a330 [85] eval_fsubr(0x19d0f649, 0x2312f0, 0x3, 0x22e800, 0x22ea08, 0xffbddd60), at 0x43b4c [86] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x2312ec, 0x2312ec), at 0x43050 [87] funcall_iclosure(0x6632b393, 0x2312e0, 0x22e800, 0x2312dc, 0x21e291, 0x66524b53), at 0x425b8 [88] funcall_closure(0x19e30ec1, 0x216598, 0x3, 0x19e307b1, 0x20, 0x19e307b0), at 0x4beac [89] interpret_bytecode_(0x19e5b591, 0x19ef7770, 0x19ef7782, 0x21e291, 0x231284, 0x231284), at 0x4fb48 [90] eval_closure(0x19e5b591, 0x216598, 0x21e291, 0x22ea08, 0xffffffff, 0x22ec00), at 0x45d9c [91] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x23126c, 0x23126c), at 0x43050 [92] C_tagbody(0x66519793, 0x231260, 0x22e800, 0x22e800, 0x9400001c, 0x1c), at 0x5b2b4 [93] eval_fsubr(0x19d0f679, 0x231238, 0x22eb70, 0x22e800, 0x22ea08, 0xffbdec40), at 0x43b4c [94] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x231238, 0x231238), at 0x43050 [95] C_letstern(0x23122c, 0x231228, 0x21e291, 0x22ea08, 0x21e291, 0x231214), at 0x58914 [96] eval_fsubr(0x19d0f4f9, 0x231200, 0x3, 0x22e800, 0x22ea08, 0xffbdee08), at 0x43b4c [97] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x2311fc, 0x2311fc), at 0x43050 [98] C_block(0x2311f0, 0x2311ec, 0x22e800, 0x2311ec, 0x21e291, 0x6651974b), at 0x5a330 [99] eval_fsubr(0x19d0f649, 0x2311d8, 0x3, 0x22e800, 0x22ea08, 0xffbdef88), at 0x43b4c [100] eval(0x21e291, 0x21e291, 0x21e291, 0x22e800, 0x2311d4, 0x2311d4), at 0x43050 Do you need some other information to help solving this problem? ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2008-04-30 17:21 Message: Logged In: YES user_id=5735 Originator: NO This bug report is now marked as "pending"/"works for me". This means that we think that we cannot reproduce the problem and cannot do anything about it. Unless you - the reporter - act within 2 weeks (e.g., by submitting a self-contained test case or answering our other recent requests), the bug will be permanently closed. Sorry about the inconvenience - we hope your silence means that you are no longer observing the problem either. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2008-04-04 14:55 Message: Logged In: YES user_id=5735 Originator: NO BTW, this message: [/opt/home/vvv/src/clisp/clisp-2.44.1/src/eval.d:527] reset() found no driver frame (sp=0xffbef9a0-0xffbeb4d0) indicates that your memory settings are likely to be incorrect. you might want to examine your oint_type_shift oint_type_len oint_type_mask oint_addr_shift oint_addr_len oint_addr_mask also, you can read the "porting" section in unix/PLATFORMS and try WIDE which should always work. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2008-03-24 15:12 Message: Logged In: YES user_id=5735 Originator: NO you, as an assembly expert, you should not have a problem debugging this :-) the function is intplus.d:I_I_plus_I() ---------------------------------------------------------------------- Comment By: Vladimir Volovich (vvv2) Date: 2008-03-24 14:46 Message: Logged In: YES user_id=1804953 Originator: YES i thought it was related to endianness because of weird results for (+ 1 1) and (+ 2 1). maybe it is 32-vs-64-bit problem. please let me know how to help debugging this problem. i have gcc, and i'll try it (i have a binary clisp package from blastwave.org which works, so it is likely that gcc build will work), but hopefully it will be possible to build clisp using Sun Studio as well. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2008-03-24 14:34 Message: Logged In: YES user_id=5735 Originator: NO oops, lispbibl.h requires gcc. so, clisp detects the endianness correctly. why did you think that is the problem? do you have gcc installed? ---------------------------------------------------------------------- Comment By: Vladimir Volovich (vvv2) Date: 2008-03-24 14:28 Message: Logged In: YES user_id=1804953 Originator: YES $ make lispbibl.h make: *** No rule to make target `lispbibl.h'. Stop. $ grep lispbibl.h Makefile -$(RM) lispbibl.h clisp.h *.i *.s *.o *.a lisp.run clisp-link makevars ansi-tests-log $ ./lisp.run -B . -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 2MW -x "(and (setq custom::*load-paths* (quote (\"/opt/home/vvv/src/clisp/clisp-2.44.1/src/\"))) (load \"/opt/home/vvv/src/clisp/clisp-2.44.1/src/init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)" WARNING: locale: no encoding 646, using ISO-8859-1 WARNING: locale: no encoding 646, using ISO-8859-1 *** - Hash table size 16777216 too large 1. Break> SYS::*BIG-ENDIAN* T 1. Break> ^D [/opt/home/vvv/src/clisp/clisp-2.44.1/src/eval.d:527] reset() found no driver frame (sp=0xffbef9e8-0xffbeb518) Exiting on signal 6 Bye. Abort (core dumped) Please let me know if you've got an idea of what further tests i should make to clarify the nature of the problem. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2008-03-24 14:17 Message: Logged In: YES user_id=5735 Originator: NO type $ make lispbibl.h $ grep BIG_ENDIAN_P lispbibl.h what is SYS::*BIG-ENDIAN* in lisp? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1924513&group_id=1355 |