Re: [Sbcl-devel] 0.9.3/2/1 die in init

[Dave R. <ld...@dr...>]

Nevermind. Zach send me a note and I tried something regarding the
address space randomization that Fedora is now doing for security
reasons. Turing that off seems to make everything work. I'm wondering if
they didn't flip the sense of switch default somewhere in gcc to mark
binaries as being compatible with this, somewhere along the line. In any
case, it looks like this isn't an sbcl problem right now.

-- Dave

On Thu, 2005-07-28 at 08:58 -0700, Dave Roberts wrote:
> So, I'm running into a bit of a mystery. I built the 0.9.3 RPMs the
> other day and things looked peachy. Everything passed the internal self
> tests, run a couple of times, in fact.
> 
> Now, I'm building this on Fedora Core 3. Yesterday, I installed a patch
> for gcc and glibc. Originally gcc was version 3.4.3 and this moved it to
> version 3.4.4. I didn't happen to notice what glibc was originally, but
> it's now 2.3.5 (the FC3 package being glibc-2.3.5-0.fc3.1).
> 
> So now, whenever I start sbcl, I have about a 50/50 chance of being
> greeted with the following SIMPLE-ERROR during init.
> 
> Two days ago, Zach Beane also reported a problem running the self-test
> with the sbcl 0.9.3 RPM on FC4.
> 
> After all this, my first thought was that the original 0.9.3 RPM I built
> might be affected by some of the latest gcc issues that have sprung up
> around gcc4. But I'm still using gcc 3.4, and the original 0.9.3 RPM I
> built was done *before* my latest upgrade, using gcc 3.4.3 rather than
> 3.4.4.
> 
> So, I uninstalled the 0.9.3 rpm and installed the 0.9.2 rpm. That was
> even worse. Rather than generating the error below half the them, it
> always crashes, and then hangs the terminal after printing about half
> the error message, forcing me to close the terminal's X window. Ctrl-C
> and Ctrl-\ don't have any effect.
> 
> The next thought was that treads could be messing things up. I built and
> installed another sbcl 0.9.3 RPM without thread support. The result is
> the same. When I start 0.9.3, it comes up about 50/50. When it does come
> up, I can evaluate *features* at the repl and verify that threads are
> not present.
> 
> To build the second version of 0.9.3, I used an older 0.8.19 rpm I had
> previously built (which includes thread support). The version 0.8.19
> seems to work fine and went through a complete 0.9.3 build with no
> issues.
> 
> I also tried 0.9.1 and that dies about half the time, and hangs the
> terminal when it does.
> 
> I also tried 0.9.0.18 and that seems to work (with threads support
> enabled).
> 
> There are a couple of possible conclusions:
> 
> 1. Something as a part of this glibc upgrade is incompatible with sbcl
> 0.9.[123]. And whatever the incompatibility is, it got added to sbcl
> after 0.9.0.18.
> 
> 2. I updated my system sometime after I built the 0.9.0.18 RPM and there
> has been a latent problem because of my build infrastructure (either gcc
> or glibc).
> 
> The error follows. It's from the 0.9.3 without threading support. In the
> threaded builds, the error report mentions the initial thread info, but
> that's about the only difference.
> 
> Is anybody running on an older version of FC3 that has not been updated
> in a couple of months with the latest gcc and/or glibc updates? If so,
> could you try the 0.9.3 rpm from SourceForge and see what happens?
> 
> Thanks,
> 
> -- Dave
> 
> 
> ---------
> 
> This is SBCL 0.9.3, 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.
> 
> debugger invoked on a SIMPLE-ERROR: Invalid external-format
> internal error #29
>     SC: 14, Offset: 4   lispobj 0x50753af
> fatal error encountered in SBCL pid 14567:
> internal error too early in init, can't recover
> The system is too badly corrupted or confused to continue at the Lisp
> level. If the system had been compiled with the SB-LDB feature, we'd
> drop
> into the LDB low-level debugger now. But there's no LDB in this build,
> so
> we can't really do anything but just exit, sorry.
> 
> -- 
> Dave Roberts <ld...@dr...>
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Sbcl-devel mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
-- 
Dave Roberts <ld...@dr...>