[cl-debian] Bug#394775: Sparc64 install fails: 'sbcl.sh install-clc' segfaults
Package: sbcl Version: 1:0.8.16-1 Severity: important I cannot install sbcl on a Sun Ultra 1. sbcl crashes during package configuration. The package isn't even marked as broken. --->8--->8--- Selecting previously deselected package common-lisp-controller. (Reading database ... 43010 files and directories currently installed.) Unpacking common-lisp-controller (from .../common-lisp-controller_4.15sarge3_all.deb) ... Setting up common-lisp-controller (4.15sarge3) ... Selecting previously deselected package sbcl. (Reading database ... 43034 files and directories currently installed.) Unpacking sbcl (from .../sbcl_1%3a0.8.16-1_sparc.deb) ... Setting up sbcl (0.8.16-1) ... /usr/lib/common-lisp/bin/sbcl.sh loading and dumping clc. /usr/lib/common-lisp/bin/sbcl.sh: line 58: 12442 Segmentation fault (core dumped) sbcl --core /usr/lib/sbcl/sbcl-dist.core --noinform --sysinit /etc/sbcl.rc --userinit /dev/null --load "/usr/lib/sbcl/install-clc.lisp" 2>/dev/null mv: cannot stat `sbcl-new.core': No such file or directory FAILED Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done ---8<---8<--- I read some old bug report leading me to believe that my locale could be a problem for SBCL. The above output is with LC_ALL=C and LANG=C on the environment. The stack trace produced below probably doesn't convey any meaningful information. --->8--->8--- $ sudo gdb sbcl /usr/lib/sbcl/core GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-linux"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `sbcl --core /usr/lib/sbcl/sbcl-dist.core --noinform --sysinit /etc/sbcl.rc --us'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x000189f8 in handle_control_stack_guard_triggered () (gdb) bt #0 0x000189f8 in handle_control_stack_guard_triggered () #1 0x0001da80 in os_install_interrupt_handlers () #2 0x0001da80 in os_install_interrupt_handlers () Previous frame identical to this frame (corrupt stack?) ---8<---8<--- Attempts to use sbcl: --->8--->8--- $ sbcl This is SBCL 0.8.16, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Segmentation fault (core dumped) ---8<---8<--- --->8--->8--- $ gdb sbcl GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-linux"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/bin/sbcl (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) This is SBCL 0.8.16, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Program received signal SIGSEGV, Segmentation fault. 0x0001516c in alloc_base_string () (gdb) bt #0 0x0001516c in alloc_base_string () #1 0x0001abb8 in main () ---8<---8<--- Please let me know if I can be of any help. -- System Information: Debian Release: 3.1 Architecture: sparc (sparc64) Kernel: Linux 2.6.18 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages sbcl depends on: ii common-lisp-controlle 4.15sarge3 This is a Common Lisp source and c ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an -- no debconf information -- J.P. Larocque is <piranha@thoughtcrime.us> and <piranha@ely.ath.cx> Encrypted/signed e-mail preferred; http://ely.ath.cx/~piranha/pgp Fpr 5612 10A8 4986 2D85 A995 252B 4C02 5E02 F61D 2E61; ID 0xF61D2E61
Hello, Let me first thank you for the bugreport, it is pretty clean and complete. On Monday 23 October 2006 01:51, J.P. Larocque wrote:
The stack trace produced below probably doesn't convey any meaningful information.
gdb does not work well with lispy environments I fear.
Loaded symbols for /lib/ld-linux.so.2 #0 0x000189f8 in handle_control_stack_guard_triggered () (gdb) bt #0 0x000189f8 in handle_control_stack_guard_triggered () #1 0x0001da80 in os_install_interrupt_handlers () #2 0x0001da80 in os_install_interrupt_handlers () Previous frame identical to this frame (corrupt stack?)
This means that it is getting a segmentation fault and thinks that it hit a 'guard page'. That page is placed just before you would overrun the control stack and if something writes to it you get a sigsegv. The handle_control_stack_guard_triggered function should then print a warning and offer the posibility to continue. It seems unlikely that the sigsegv comes from the control stack. I fear that it just gets the sigsegv because it is trying to use a memory region it cannot use.
Program received signal SIGSEGV, Segmentation fault. 0x0001516c in alloc_base_string () (gdb) bt #0 0x0001516c in alloc_base_string () #1 0x0001abb8 in main ()
This looks like a 'normal' sigsegv (we also use it to control memory allocation).
Please let me know if I can be of any help.
could you send me the output of cat /proc/self/maps and strace /usr/bin/sbcl --core /usr/lib/sbcl/sbcl-dist.core --sysinit /dev/null --userinit /dev/null Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
On Tue, Oct 31, 2006 at 08:37:11AM +0100, Peter Van Eynde wrote:
could you send me the output of
cat /proc/self/maps
---8<---8<--- 00010000-00014000 r-xp 00000000 08:01 6201 /bin/cat 00022000-00024000 rwxp 00002000 08:01 6201 /bin/cat 00024000-00046000 rwxp 00024000 00:00 0 [heap] f7d24000-f7e78000 r--p 00000000 fe:00 16461 /usr/lib/locale/locale-archive f7e78000-f7fac000 r-xp 00000000 08:01 22628 /lib/libc-2.3.2.so f7fac000-f7fb8000 ---p 00134000 08:01 22628 /lib/libc-2.3.2.so f7fb8000-f7fc4000 rwxp 00130000 08:01 22628 /lib/libc-2.3.2.so f7fc4000-f7fc6000 rwxp f7fc4000 00:00 0 f7fd0000-f7fea000 r-xp 00000000 08:01 22625 /lib/ld-2.3.2.so f7ff8000-f7ffa000 rwxp 00018000 08:01 22625 /lib/ld-2.3.2.so ff8f0000-ff91a000 rw-p ff8f0000 00:00 0 [stack] --->8--->8---
and strace /usr/bin/sbcl --core /usr/lib/sbcl/sbcl-dist.core --sysinit /dev/null --userinit /dev/null
---8<---8<--- execve("/usr/bin/sbcl", ["/usr/bin/sbcl", "--core", "/usr/lib/sbcl/sbcl-dist.core", "--sysinit", "/dev/null", "--userinit", "/dev/null"], [/* 41 vars */]) = 0 uname({sys="Linux", node="gyral", ...}) = 0 brk(0) = 0x22000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=22531, ...}) = 0 mmap(NULL, 22531, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f90000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0\36"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=10444, ...}) = 0 mmap(NULL, 74736, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xf7f7c000 mprotect(0xf7f80000, 58352, PROT_NONE) = 0 mmap(0xf7f8c000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xf7f8c000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libm.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0\234"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=527020, ...}) = 0 mmap(NULL, 591312, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xf7ee8000 mprotect(0xf7f66000, 75216, PROT_NONE) = 0 mmap(0xf7f68000, 73728, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x70000) = 0xf7f68000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\1\316"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1292436, ...}) = 0 mmap(NULL, 1362352, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xf7d98000 mprotect(0xf7ecc000, 100784, PROT_NONE) = 0 mmap(0xf7ed8000, 49152, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x130000) = 0xf7ed8000 mmap(0xf7ee4000, 2480, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7ee4000 close(3) = 0 munmap(0xf7f90000, 22531) = 0 uname({sys="Linux", node="gyral", ...}) = 0 mmap(0x10000000, 83886080, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000000 mmap(0x28000000, 67108864, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x28000000 mmap(0x30000000, 134217728, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x30000000 mmap(0x40000000, 134217728, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x40000000 mmap(0xf800000, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xf800000 brk(0) = 0x22000 brk(0x44000) = 0x44000 brk(0) = 0x44000 fstat64(1, {st_mode=S_IFREG|0644, st_size=3212, ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f96000 write(1, "This is SBCL 0.8.16, an implemen"..., 362This is SBCL 0.8.16, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. ) = 362 open("/etc/localtime", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7f94000 read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 8192) = 1017 close(3) = 0 munmap(0xf7f94000, 8192) = 0 open("/usr/lib/sbcl/sbcl-dist.core", O_RDONLY) = 3 read(3, "SBCL\0\0\17\24\0\0\0\3\0\0\0\3\0\0\17;\0\0\0!\0\0\0v\0"..., 8192) = 8192 mmap(0x10000000, 20176896, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0x10000000 mmap(0x28000000, 5267456, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x1340000) = 0x28000000 mmap(0x40000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x1846000) = 0x40000000 rt_sigaction(SIGILL, {0x1ca1c, [PIPE ALRM URG TSTP CHLD IO XCPU XFSZ VTALRM PROF WINCH USR1 USR2], SA_RESTART|SA_SIGINFO}, NULL, 0xf7dcb0ec, 3) = 0 rt_sigaction(SIGEMT, {0x1cd1c, [PIPE ALRM URG TSTP CHLD IO XCPU XFSZ VTALRM PROF WINCH USR1 USR2], SA_RESTART|SA_SIGINFO}, NULL, 0xf7dcb0ec, 3) = 0 rt_sigaction(SIGSEGV, {0x1da0c, [PIPE ALRM URG TSTP CHLD IO XCPU XFSZ VTALRM PROF WINCH USR1 USR2], SA_RESTART|SA_SIGINFO}, NULL, 0xf7dcb0ec, 3) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV (core dumped) +++ --->8--->8--- Thanks, -- J.P. Larocque is <piranha@thoughtcrime.us> and <piranha@ely.ath.cx> Encrypted/signed e-mail preferred; http://ely.ath.cx/~piranha/pgp Fpr 5612 10A8 4986 2D85 A995 252B 4C02 5E02 F61D 2E61; ID 0xF61D2E61
Hello, Your logs show that there is a memory layout conflict in sbcl: On Saturday 04 November 2006 10:45, J.P. Larocque wrote:
cat /proc/self/maps
---8<---8<--- 00010000-00014000 r-xp 00000000 08:01 6201 /bin/cat 00022000-00024000 rwxp 00002000 08:01 6201 /bin/cat 00024000-00046000 rwxp 00024000 00:00 0 [heap] f7d24000-f7e78000 r--p 00000000 fe:00 16461 /usr/lib/locale/locale-archive
And then sbcl does an allocation of the linkage tables from 0xf800000 upto 0x10000000. This goes right over where the libraries are in memory: src/compiler/sparc/parms.lisp ... (def!constant linkage-table-space-start #x0f800000) (def!constant linkage-table-space-end #x10000000) and in the strace:
mmap(0xf800000, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xf800000
A while later it crashes. To fix this one would need access to a sparc64 machine to further debug this problem, but vore is still down so I cannot use a debian machine to investigate this. If you can recompile sbcl you could try to change the parms.lisp file move the LT to some other place. Maybe #xa0000000 to #xa0800000? Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
On Mon, Nov 06, 2006 at 02:39:13PM +0100, Peter Van Eynde wrote:
Hello,
Your logs show that there is a memory layout conflict in sbcl:
On Saturday 04 November 2006 10:45, J.P. Larocque wrote:
cat /proc/self/maps
---8<---8<--- 00010000-00014000 r-xp 00000000 08:01 6201 /bin/cat 00022000-00024000 rwxp 00002000 08:01 6201 /bin/cat 00024000-00046000 rwxp 00024000 00:00 0 [heap] f7d24000-f7e78000 r--p 00000000 fe:00 16461 /usr/lib/locale/locale-archive
And then sbcl does an allocation of the linkage tables from 0xf800000 upto 0x10000000. This goes right over where the libraries are in memory:
src/compiler/sparc/parms.lisp ... (def!constant linkage-table-space-start #x0f800000) (def!constant linkage-table-space-end #x10000000)
and in the strace:
mmap(0xf800000, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xf800000
A while later it crashes. To fix this one would need access to a sparc64 machine to further debug this problem, but vore is still down so I cannot use a debian machine to investigate this.
Hi Peter, if yo want i could try to put up a sparc64 wit Debian on it and attac it to the net. Cheers, RalfD
If you can recompile sbcl you could try to change the parms.lisp file move the LT to some other place. Maybe #xa0000000 to #xa0800000?
Groetjes, Peter
-- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ "God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|
_______________________________________________ cl-debian mailing list cl-debian@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-debian
On Mon, Nov 06, 2006 at 02:39:13PM +0100, Peter Van Eynde wrote:
If you can recompile sbcl you could try to change the parms.lisp file move the LT to some other place. Maybe #xa0000000 to #xa0800000?
Disclosure: this is well into the realm of deep magic for me. =) I'd love to recompile, but I can't find a host CL to build SBCL with. The stable package build-depends on sbcl, which of course can't work. Stable's clisp segfaults on installation, too. Both the Debian stable[1] and upstream 0.9.18[2] versions of SBCL won't build with "gcl -batch". Even the SPARC binary on the SBCL web site fails[3]. Am I missing any ideas on how to get this going? 1. GNUmakefile:72: depend: No such file or directory 2. Error in GET-MACRO-CHARACTER [or a callee]: NIL is not of type READTABLE 3. After startup banner: ---8<---8<--- fatal error encountered in SBCL pid 9293: maximum interrupt nesting depth (32) exceeded LDB monitor ldb> --->8--->8--- -- J.P. Larocque: <piranha@thoughtcrime.us>, <piranha@ely.ath.cx>
Your message dated Mon, 17 Sep 2007 19:47:11 +0000 with message-id <E1IXMYp-0006vd-Iw@ries.debian.org> and subject line Bug#394775: fixed in sbcl 1:1.0.9.0-1 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database)
participants (5)
-
J.P. Larocque -
J.P. Larocque -
owner＠bugs.debian.org -
Peter Van Eynde -
rm＠tuxteam.de