From: Dr. W. F. <we...@su...> - 2005-12-19 14:19:13
|
On Fri, Dec 16, 2005 at 10:37:02AM -0500, Sam Steingold wrote: > > * Dr. Werner Fink <jreare@fhfr.qr> [2005-12-16 15:12:36 +0100]: > > > > OK ... beside this, the macro defined_class_length should use size_t > > instead of ULONG type at least on 64-bit platforms. The g++ does not > > like ULONG in a comparision with gcv_object_t* pointers. > > I fixed this differently earlier this week (aint instead of size_t) > > > Also () around a structure is not that good for modern c++ compilers. > > why? > > > Beside this I had removed the `inline' from check_faddress_valid() > > to get it to link on SuSE Linux 10.0 x86_64. The g++ version is > > g++ (GCC) 4.0.2 20050901. > > OK. > > > But nevertheless the last lines are: > > > > echo '(setq *clhs-root-default* "http://www.lisp.org/HyperSpec/")' >> config.lisp > > ./lisp.run -B . -Efile UTF-8 -Eterminal UTF-8 -Emisc 1:1 -norc -m 1400KW -x "(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit)) (ext::exit t)" > > STACK depth: 22389 > > make: *** [interpreted.mem] Segmentation fault > > the problem is > if you compile with "-g", then the crash is > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004896e5 in gcv_object_t::operator object (this=0x400000091f358) > at lispbibl.d:4179 > 4179 nonimmprobe(one_o); > > that is because 0x400000091f358 is not a valid pointer. > > (gdb) up > #1 0x000000000068124e in with_gc_statistics ( > fun=0x4190f4 <do_gar_col_simple>) at predtype.d:3134 > 3134 var object flag = Symbol_value(S(gc_statistics_stern)); > (gdb) p &(symbol_tab_data.S_gc_statistics_stern) > $1 = (symbol_ *) 0x91f350 > > now, look at 0x91f350 > and 0x400000091f358 > > the last digit (8 vs 0) is due to the "object" vs "symbol_" shift, > but the _first_ digit is totally off. > if you walk through the horrible maze of > pgci_types_pointable -> ngci_pointable (DEBUG_GCSAFETY) > vs types_pointable (normal) -> type_pointable -> pointable -> ... > you might be able to discover where on of the foo_shift is used > incorrectly. Hmmm ... it seems to be a bit different: Program received signal SIGSEGV, Segmentation fault. 0x00000000008535b4 in with_gc_statistics (fun=0x435202 <do_gar_col_simple>) at lispbibl.d:4179 4179 nonimmprobe(one_o); Warning: the current language does not match this frame. (gdb) up #1 0x000000000041b267 in gar_col_simple () at spvw_garcol.d:2405 2405 with_gc_statistics(&do_gar_col_simple); # GC and statistics (gdb) p &(symbol_tab_data.S_gc_statistics_stern) $1 = (symbol_ *) 0xb52168 (gdb) and the chrash happens with this lisp code (let ((ht (make-hash-table :test 'ext:fasthash-eq))) (defstruct ht-test-struct a b c) (setq x (make-ht-test-struct :a 1 :b 2 :c ht)) (setf (gethash ht ht) ht (gethash x ht) 12) (setq x (read-from-string (with-standard-io-syntax (write-to-string x))) ht (ht-test-struct-c x)) (setf (ht-test-struct-a x) (ext:! <X>)) (ext:gc) (list (eq (gethash ht ht) ht) (gethash x ht))) (quit) with the numbers <X> = 17,20,21,22,23,.... In other words, the numbers 1 ... 16, 18, and 19 do work here on this x86_64 at least upto the (quit). > I am rather lost. ACK ... IMHO the clisp engine needs some changes to make the code more handy. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr |