FS#16761 - [sbcl] ships with debugger disabled by default

Attached to Project: Arch Linux
Opened by Einar Lielmanis (spic) - Wednesday, 21 October 2009, 01:01 GMT
Last edited by Jürgen Hötzel (juergen) - Wednesday, 13 January 2010, 17:53 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jürgen Hötzel (juergen)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

sbcl (1.0.31-2) ships with the debugger disabled by default, which is wrong (and annoying), as any error or typo in the sbcl shell will immediately terminate it.


Steps to reproduce:

% sbcl
This is SBCL 1.0.31, an implementation of ANSI Common Lisp.
...
* abcd
unhandled UNBOUND-VARIABLE in thread #<SB-THREAD:THREAD "initial thread" RUNNING {1002A26011}>:
...
unhandled condition in --disable-debugger mode, quitting
%

Apparently it happens because --script is used in PKGBUILD to dump a core with some modified paths, and --script disables debugger, so dumped core has no debugger either.


Temporary workaround:

To reenable debugger in the shell, run (sb-ext:enable-debugger)
This task depends upon

Closed by  Jürgen Hötzel (juergen)
Wednesday, 13 January 2010, 17:53 GMT
Reason for closing:  Fixed
Comment by Leslie Polzer (skypher) - Tuesday, 01 December 2009, 22:11 GMT
--- fix-source-path.lisp (revision 60185)
+++ fix-source-path.lisp (working copy)
This patch fixes it and also gets rid of the IGNORE-ERRORS:

@@ -15,8 +15,8 @@
`(("SYS:SRC;**;*.*.*" ,src)
("SYS:CONTRIB;**;*.*.*" ,contrib))))

-(ignore-errors
- (sb-ext:gc :full t)
- (sb-ext:save-lisp-and-die "sbcl-new.core"))
+(sb-ext:gc :full t)
+(sb-ext:enable-debugger)
+(sb-ext:save-lisp-and-die "sbcl-new.core")
Comment by Leslie Polzer (skypher) - Tuesday, 01 December 2009, 22:15 GMT
Err, not sure why the patch got jumbled. The comment "This patch fixes..." and the blank line after it need to be deleted.
Comment by Leslie Polzer (skypher) - Tuesday, 01 December 2009, 22:16 GMT
Or use this: http://paste.lisp.org/display/91394
Comment by Jürgen Hötzel (juergen) - Wednesday, 02 December 2009, 21:23 GMT
@Leslie: Thanks!

Sadly compilation of current trunk (1.32) fails (also prev. 1.31):

; SYS:SRC;CODE;RUN-PROGRAM.FASL.NEWEST written
; compilation finished in 0:00:00.793

debugger invoked on a UNDEFINED-ALIEN-ERROR in thread #<THREAD "initial thread" RUNNING {10029A3071}>:
Undefined alien: "waitpid"

any contribution appreciated.
Comment by Leslie Polzer (skypher) - Wednesday, 02 December 2009, 21:53 GMT
1.0.33 at least builds for me without issues.

Your problem is familiar to me, though:

See http://thread.gmane.org/gmane.lisp.steel-bank.general/2598/focus=2602 for a possible solution.
If that doesn't help you should probably try 1.0.33 and ask on sbcl-help.
Comment by Leslie Polzer (skypher) - Thursday, 03 December 2009, 09:44 GMT
1.0.32 builds correctly here too.
Comment by Jürgen Hötzel (juergen) - Thursday, 03 December 2009, 16:54 GMT
@Leslie: Confirmed. 1.0.33 builds fine on i686. I use x86_64 as primary build environment.

I just release the i686 update and will keep this bug open until x86_64 release is available from upstream:

http://www.sbcl.org/platform-table.html:
Comment by Leslie Polzer (skypher) - Saturday, 05 December 2009, 10:03 GMT
x86_64 bug analysis: http://bbs.archlinux.org/viewtopic.php?pid=667471#p667471

Upstream bug filed as well: https://bugs.launchpad.net/sbcl/+bug/492783
Comment by Leslie Polzer (skypher) - Wednesday, 06 January 2010, 12:09 GMT
Ultimately I'd like to see this bug fixed in SBCL, but I'd also really like to get an up to date x86-64 package as soon as possible.

Can we just unset LDFLAGS before building until there's a proper fix?
Comment by Jürgen Hötzel (juergen) - Thursday, 07 January 2010, 09:20 GMT
just setting LDFLAGS="-Wl,--hash-style=gnu" doesnt help. Still results in

debugger invoked on a UNDEFINED-ALIEN-ERROR in thread #<THREAD
"initial thread" RUNNING
{1002A80071}>:
Undefined alien: "waitpid"


Comment by Leslie Polzer (skypher) - Thursday, 07 January 2010, 09:28 GMT
Thanks. I'm going to check this myself and solve this. I've installed x86-64 on a VM yesterday.
Comment by Jürgen Hötzel (juergen) - Thursday, 07 January 2010, 23:45 GMT
This should be fixed now:

/etc/makepkg.conf provides default LDFLAGS.

sbcl uses LINKFLAGS and OS_LIBS (libdl) to build LDFLAGS in file Config.x86_64-linux. But we use "make -e" to build sbcl, so the required libdl wasn't used when building os-provides-dlopen-test

I just release the x86_64 build. Please confirm.

Loading...