#234 cannot handle package with gazillion symbols
<http://article.gmane.org/gmane.lisp.clisp.devel:13120>
,290,000: 54.6% ETA: 00:47:35>..........<8,300,000:
54.6% ETA: 00:47:20>........
..<8,310,000: 54.7% ETA: 08:28:25>.....
*** - handle_fault error2 ! address = 0x9d4ec2c8 not in
[0x339bc000,0x453749e0)
!
Breakpoint 10, sigsegv_handler_failed (address=0xc9d4ec2c8)
at spvw_sigsegv.d:29
29 fprintf(stderr,GETTEXTL(NLstring "SIGSEGV
cannot be cured. Fault addre
ss = 0x%x." NLstring),
(gdb) where
#0 sigsegv_handler_failed (address=0xc9d4ec2c8) at
spvw_sigsegv.d:29
#1 0x0000000000405f70 in sigsegv_handler
(fault_address=0xc9d4ec2c8,
serious=1) at spvw_sigsegv.d:44
#2 0x0000000000546d39 in sigsegv_handler
(sig=-1655782712, sip=0x7fbfef8140,
ucp=0x52) at handler-unix.c:214
#3 <signal handler called>
#4 0x00000000004beb65 in symtab_lookup
(string=0x16000445c21568,
symtab=0x17000333fae410, sym_=0x727b60) at
package.d:220
*** why is sym_ 32-bit?!
#5 0x00000000004bff21 in find_symbol
(string=0x16000445c21568,
pack=0xc000333fae438, sym_=0x727b60) at package.d:711
#6 0x00000000004c01f5 in intern (string=0x16000445c21568,
pack=0xc000333fae438, sym_=0x727b60) at package.d:787
#7 0x00000000004c49c9 in C_intern () at package.d:2146
#8 0x00000000004311e6 in interpret_bytecode_
(closure=0x9000333f51b98,
codeptr=0x333f51b60, byteptr=0x333f51b90
"\031\004") at eval.d:6862
#9 0x000000000042da94 in funcall_closure
(closure=0x9000333f51b98,
args_on_stack=2) at eval.d:5641
#10 0x000000000042bd79 in funcall (fun=0x4000333e1fb20,
args_on_stack=2)
at eval.d:4812
#11 0x00000000004310e9 in interpret_bytecode_
(closure=0x9000333f61c00,
codeptr=0x333f52658, byteptr=0x333f539e8 "\223") at
eval.d:6859
#12 0x000000000042d8e5 in funcall_closure
(closure=0x9000333f78920,
args_on_stack=0) at eval.d:5622
#13 0x000000000042bd79 in funcall (fun=0x4000333e21970,
args_on_stack=0)
at eval.d:4812
#14 0x0000000000430ddc in interpret_bytecode_
(closure=0x9000333fbee00,
codeptr=0x333fbe7c0, byteptr=0x333fbe85a "o") at
eval.d:6847
#15 0x000000000042d8e5 in funcall_closure
(closure=0x9000333fbee00,
args_on_stack=6) at eval.d:5622
#16 0x000000000042bd79 in funcall (fun=0x4000333e79128,
args_on_stack=7)
at eval.d:4812
#17 0x0000000000430c0b in interpret_bytecode_
(closure=0x9000333fbf508,
codeptr=0x333fbf078, byteptr=0x333fbf11f "") at
eval.d:6841
#18 0x000000000042834f in eval_closure
(closure=0x900033404faa0) at eval.d:3777
#19 0x00000000004246de in eval1 (form=0x40000ccccd6e10)
at eval.d:2931
#20 0x0000000000424221 in eval (form=0x40000ccccd6e10)
at eval.d:2810
#21 0x0000000000440b93 in C_unwind_protect () at
control.d:1904
#22 0x0000000000424ebc in eval_fsubr (fun=0xc0003339da560,
args=0x40000ccccd6cd0) at eval.d:3084
#23 0x0000000000424746 in eval1 (form=0x40000ccccd6cb0)
at eval.d:2941
#24 0x0000000000424221 in eval (form=0x40000ccccd6cb0)
at eval.d:2810
#25 0x00000000004405dd in C_multiple_value_bind () at
control.d:1815
#26 0x0000000000424ebc in eval_fsubr (fun=0xc0003339da4e8,
args=0x40000ccccd6ca0) at eval.d:3084
#27 0x0000000000424746 in eval1 (form=0x40000ccccd6c70)
at eval.d:2941
#28 0x0000000000424221 in eval (form=0x40000ccccd6c70)
at eval.d:2810
#29 0x00000000004245be in eval1 (form=0x40000ccccd6c70)
at eval.d:2899
#30 0x0000000000424221 in eval (form=0x40000ccccd6e20)
at eval.d:2810
#31 0x00000000004e4957 in C_read_eval_print () at
debug.d:311
#32 0x000000000042ca98 in funcall_subr
(fun=0x10000006eda40, args_on_stack=2)
at eval.d:5201
#33 0x000000000042bd5a in funcall (fun=0x40000006fa2b0,
args_on_stack=2)
at eval.d:4810
#34 0x000000000043102c in interpret_bytecode_
(closure=0x9000333b768e0,
codeptr=0x333b24198,
byteptr=0x333b241c2
"\037\ak\a\211\b\005.\tQ\031\001I\017\v")
at eval.d:6856
#35 0x000000000042da94 in funcall_closure
(closure=0x9000333b768e0,
args_on_stack=0) at eval.d:5641
#36 0x000000000042bd13 in funcall (fun=0x9000333b768e0,
args_on_stack=0)
at eval.d:4805
#37 0x00000000004410a1 in C_driver () at control.d:1960
#38 0x00000000004311e6 in interpret_bytecode_
(closure=0x9000333b25d68,
codeptr=0x333b25c18, byteptr=0x333b25c3a "o") at
eval.d:6862
#39 0x000000000042da94 in funcall_closure
(closure=0x9000333b25d68,
args_on_stack=0) at eval.d:5641
#40 0x000000000042bd13 in funcall (fun=0x9000333b25d68,
args_on_stack=0)
at eval.d:4805
#41 0x0000000000431f2b in interpret_bytecode_
(closure=0x9000333b8e1c8,
codeptr=0x333a367c8, byteptr=0x333a3680e "") at
eval.d:6912
#42 0x000000000042da94 in funcall_closure
(closure=0x9000333b8e1c8,
args_on_stack=0) at eval.d:5641
#43 0x000000000042bd13 in funcall (fun=0x9000333b8e1c8,
args_on_stack=0)
at eval.d:4805
#44 0x00000000004e4e14 in driver () at debug.d:380
#45 0x00000000004187d5 in main (argc=7,
argv=0x7fbfefaff8) at spvw.d:3016
(gdb)
in frame 4:
(gdb) p index
$5 = 3431404
(gdb) p string_hashcode(string)
warning: Unable to restore previously selected frame.
$6 = 13272486
(- 13272486 3431404) = 9841082 = (* 2 59 83399)
this makes me think that CLISP somehow does not like
huge packages.
XOUT(symtab) ==> segfault
symtab is a vector of length 3: #(4920541 #(...) 8688818)
the internal vector causes the crash.
a simple test does catch the bug:
[1]> (defun test-package (num)
(when (find-package "TEST") (delete-package "TEST"))
(make-package "TEST" :use nil)
(dotimes (i num) (intern (format nil "SYM-~d" i) "TEST"))
(loop :repeat 100 :do
(let ((name (format nil "SYM-~d" (random num))))
(unless (find-symbol name "TEST")
(error "~S not found" name)))))
TEST-PACKAGE
[2]> (compile 'test-package )
TEST-PACKAGE ;
NIL ;
NIL
[3]> (time (test-package 10000000))
Real time: 161.88853 sec.
Run time: 161.75 sec.
Space: 700735112 Bytes
GC: 218, GC time: 90.44 sec.
NIL
[4]> (time (test-package 100000000))
*** - handle_fault error2 ! address = 0xa4c333a8 not in
[0x33974000,0x4c059bc0)
!
SIGSEGV cannot be cured. Fault address = 0xa4c333a8.
Segmentation fault
(this is on AMD64)
Logged In: YES
user_id=5735
thank you for your bug report.
the bug has been fixed in the CVS tree.
you can either wait for the next release (recommended)
or check out the current CVS tree (see http://clisp.cons.org\)
and build CLISP from the sources (be advised that between
releases the CVS tree is very unstable and may not even build
on your platform).