SBCL epicly crashes.

syb · 2011-07-30 19:02:51

Has anyone encountered this problem? Any instance of sbcl crashes with a segmentation fault message. This happened after a whole upgrade of my arch box. The fact that it came with the new linux version and many other stuff makes me suspect.

I had tried with ABS and AUR PKGBUILD scripts and either case oddly crashed with this message:
http://pastebin.com/5erAvG7d

I don't know where to go from here. Any clue someone?

Current version:
SBCL 1.0.50-1
Linux archy 3.0-ARCH #1 SMP PREEMPT Thu Jul 28 13:37:15 CEST 2011 x86_64

Inxsible · 2011-07-30 19:16:27

kernel 3.0 is in testing....Please start threads in appropriate forums

Moving...

syb · 2011-07-30 19:34:08

Hmmm, sorry about that

falconindy · 2011-07-30 19:59:54

Yep. Appears to choke on the "malformed" kernel version. I can replicate this on 3.0-ARCH, but it compiles fine on my custom kernel which is still called 3.0.0. File a bug report (upstream), please.

Last edited by falconindy (2011-07-30 20:00:28)

Andertxu · 2011-08-06 13:57:00

Same here . maxima crashes .

Also xdosemu crashes too even with "vm.mmap_min_addr = 0" on /etc/sysctl.conf

Repositorio : extra
Nombre : sbcl
Versión : 1.0.50-1

Repositorio : community
Nombre : dosemu
Versión : 1.4.0-3
URL : http://www.dosemu.org/

Linux archlinux 3.0-ARCH #1 SMP PREEMPT Thu Jul 28 13:37:15 CEST 2011 x86_64 Genuine Intel(R) CPU T1600 @ 1.66GHz GenuineIntel GNU/Linux

hakkum · 2011-08-08 00:44:17

Hey guys I had the same problem but have a fix for you. If you install the 'sbcl-git' from the AUR, it will work. The problem however is that building a new version of SBCL requires an old one. A workaround for this is to download a binary of SBCL and use that to build and install the 'sbcl-git' version. Here are the steps I took to get it working:

- download http://discontinuity.info/~pkhuong/misc … ry.tar.bz2 into a temporary directory and extract:
EDIT: if possible, please download file from this mirror instead: http://massmirror.com/9b0f555b317bb33e3 … 034e7.html

$ cd ~/sbcltmp
$ tar xf sbcl-1.0.50.x-3.0-fix-binary.tar.bz2

- cd into sbcl-1.0.50.x-3.0-fix and create a symlink called 'sbcl' to 'run-sbcl.sh':

$ cd sbcl-1.0.50.x-3.0-fix
$ ln -s run-sbcl.sh sbcl

- make 'run-sbcl.sh' executable:

$ chmod +x run-sbcl.sh

- using yaourt, install 'sbcl-git' including newly created 'sbcl' in path, making sure to skip dependency checks:
note: (because you're skipping dependency checks, ensure that you already have 'glibc', 'git', and 'texinfo' installed

$ PATH=$PATH:/home/<user>/sbcltmp/sbcl-1.0.50.x-3.0-fix yaourt -Sdd sbcl-git

- clean up temp files:

$ cd
$ rm -rf sbcltmp

Everything should be working just fine after that. If you don't use yaourt, just remember to skip the dependency checks when you run 'makepkg'. Let me know if you have any trouble.

Last edited by hakkum (2011-08-08 00:48:37)

vitaly · 2011-08-08 01:41:10

Cross-compiling also works. Get SBCL from git, run ./make.sh --xc-host="clisp -q -norc" in SBCL directory.

simon-nicholls · 2011-08-08 10:31:21

Thanks Hakkum, that did the trick!

Andertxu · 2011-08-08 13:41:56

Why don't you upload to [extra] the fixed and patched version ?

Inxsible · 2011-08-08 13:48:47

Andertxu wrote:

Why don't you upload to [extra] the fixed and patched version ?

because hakkum is not a TU/developer, so he can't.

And if this is an upstream bug like falconindy has mentioned, it will have to be fixed by the upstream devs to be able to get into [extra]. The Arch devs do not patch any software (unless its required for a functioning Arch system)

Until, then you will have to keep using the package from AUR which is not that a big deal.

hakkum · 2011-08-08 16:34:45

And seeing as the fix has already been incorporated into the git version, it shouldn't be too long before it makes it's way to mainstream.

And PS that fix is a binary for 64-bit machines only, so if you're on 32-bit, do what vitaly says and build it with clisp. If you look at the PKGBUILD, you will see 'make.sh --prefix=/usr'. Just change that to 'make.sh --prefix=/usr --xc-host="clisp -q -norc"' and make sure you have clisp installed.

falconindy · 2011-08-10 03:32:54

Disclaimer: I'm not a lisper. I do however, know git, so I've backported the patch and rebuilt sbcl on my 3 digit kernel (oooh fancy).

Feedback for these is appreciated. I can push to extra if they're deemed acceptable.

64bit: http://pkgbuild.com/~dreisner/sbcl-1.0. … pkg.tar.xz
32bit: http://pkgbuild.com/~dreisner/sbcl-1.0. … pkg.tar.xz

hakkum · 2011-08-10 05:56:21

falconindy,

I personally am opposed to patches as much as possible. As the fix is obviously already implemented in the git version, all we need to do is wait for upstream to release an updated version. However, having SBCL in extra work properly is just as important as keeping it vanilla. If you don't mind I'd like to check on #sbcl (Freenode) to see if they can push for a fix upstream before anything else.

Also I noticed that in the repos, the 64bit is on version 1.0.50-1 whereas 32bit is on version 1.0.49-1. Is that a typo on the 32bit part?

falconindy · 2011-08-10 13:18:01

Great. I'm glad I took time out of my day to build this. Your feedback is noted.

edit: From IRC:

09:16            joshe  » Releases generally happen around the beginning of each month.
09:17            joshe  » No reason you shouldn't fix your distro's package in the 
                          meantime, I've done that a number of times.

Now that I've gone out of my way again, would you perhaps like to comment on the packages I've built?

Last edited by falconindy (2011-08-10 13:29:56)

toofishes · 2011-08-10 13:24:25

hakkum wrote:

falconindy,
I personally am opposed to patches as much as possible. As the fix is obviously already implemented in the git version, all we need to do is wait for upstream to release an updated version. However, having SBCL in extra work properly is just as important as keeping it vanilla. If you don't mind I'd like to check on #sbcl (Freenode) to see if they can push for a fix upstream before anything else.
Also I noticed that in the repos, the 64bit is on version 1.0.50-1 whereas 32bit is on version 1.0.49-1. Is that a typo on the 32bit part?

hakkum,

I personally am opposed to users that think time is free for our developers, and chastise their work and dedication toward fixing user problems. All we need to do is eliminate all our users and we won't have this problem anymore. Keeping Arch a developers-only distro is just as important as allowing others to know we exist.

How does that sound to you? Because your comments were really a slap in the face to developers ever caring about users.

Oh, and this fix is already "upstream" as was previously noted.

hakkum · 2011-08-10 14:27:43

Wow sorry. I didn't mean to upset you. I totally appreciate your work, falconindy, and actually I used your pkg for my 32 bit machine...all is working great. Thanks! However, I thought that it's 'The Arch Way' to keep packages as untouched as possible. The way I see it, if one were to install SBCL, and get a seg fault, he/she'd come looking for a solution, possibly ending up at this thread (they could knowingly use falconindy's patched pkg). Eventually enough users would voice the issues to the SBCL devs, and a release would be expedited and all would be good. If however, a user installs a distro-patched SBCL, not knowing it's been patched, all will work fine from the start. The SBCL devs might not know of there being an issue, as word would never get to them. They wouldn't be inspired or pushed to produce new releases and projects would die, forks made, etc.

That's just how I see it anyways. That's what I get from the philosophy of this amazing distro too. I truly did not mean to offend you or dismiss your work falconindy. And I didn't mean to get attacked either toofishes, though I do see why it's deserved. Again I apologize to both of you and absolutely 100% am indebted to the work you do.

falconindy · 2011-08-10 14:44:00

hakkum wrote:

If however, a user installs a distro-patched SBCL, not knowing it's been patched, all will work fine from the start. The SBCL devs might not know of there being an issue, as word would never get to them. They wouldn't be inspired or pushed to produce new releases and projects would die, forks made, etc.

Yeah, you've completely misunderstood what I've done. The patch I backported was straight from upstream. There is no "distro patch". The "git version" you speak of pulls directly from upstream git repo at sourceforge. No one's doing anything here that upstream isn't aware of.

sykopomp · 2011-08-11 17:16:05

Considering that the current sbcl tag is *completely unusable* on linux-3.0, and that pulling and building SBCL from git is not only acceptable, but encouraged, I don't see what the problem is with just replacing 1.0.50 with the latest git version until .51 is tagged. It's going to be another two weeks or so before they actually get around to doing so.

Arch Linux

#1 2011-07-30 19:02:51

SBCL epicly crashes.

#2 2011-07-30 19:16:27

Re: SBCL epicly crashes.

#3 2011-07-30 19:34:08

Re: SBCL epicly crashes.

#4 2011-07-30 19:59:54

Re: SBCL epicly crashes.

#5 2011-08-06 13:57:00

Re: SBCL epicly crashes.

#6 2011-08-08 00:44:17

Re: SBCL epicly crashes.

#7 2011-08-08 01:41:10

Re: SBCL epicly crashes.

#8 2011-08-08 10:31:21

Re: SBCL epicly crashes.

#9 2011-08-08 13:41:56

Re: SBCL epicly crashes.

#10 2011-08-08 13:48:47

Re: SBCL epicly crashes.

#11 2011-08-08 16:34:45

Re: SBCL epicly crashes.

#12 2011-08-10 03:32:54

Re: SBCL epicly crashes.

#13 2011-08-10 05:56:21

Re: SBCL epicly crashes.

#14 2011-08-10 13:18:01

Re: SBCL epicly crashes.

#15 2011-08-10 13:24:25

Re: SBCL epicly crashes.

#16 2011-08-10 14:27:43

Re: SBCL epicly crashes.

#17 2011-08-10 14:44:00

Re: SBCL epicly crashes.

#18 2011-08-11 17:16:05

Re: SBCL epicly crashes.

Board footer