[Openmcl-devel] Clozure Common Lisp Version 1.2-r7902S (LinuxX8664)

[Gary Byers]

On Tue, 11 Mar 2008, Ralf Stoye wrote:

> Hello,
> just a small update to the vserver problems:
>
> The provider adjusted the available pages, and now i am able to
> reserve about 35GB for ccl.
> Using 10GB per instance of ccl, fork isn't a problem anymore.
> (really good service, asked for that at 17:00, done at 18:00, for a
> product which costs 8€ a month)
>
> The remaining Problems are:
>
> a) when using "to much" memory, mcl just hangs instead of throwing
> memory errors
> is that a consequence of the bug you told about? ("having to do with
> whether
> some GC data structures are initialized correctly")

That caused death on startup and should be fixed in svn/cvs.

It's hard to know what causes the failure you describe.  It's
possible that an out-of-memory condition was reliably detected
and the lisp recursed a little to tell you about it and the
stack page it touched wasn't there.  (It's also possible that
it failed in some more mundane way, but because of "overcommit"
- Google for "linux overcommit" - memory strategies it's not
always clear what it means to "have memory.")

Usually, heavy paging activity is a precursor to actually
running out of memory.  If there's just some sort of surprise
failure after running for a while and using a lot,of memory,
it's likely that the problem lies elsewhere.


>
> b) a new problem: out of the box, i was unable to use ffigen.
>      the installed one (ffigen-bin-linuxx8664-
> gcc-4.0.0-2007-09-29-23-10-35.tar.gz) immediately exits with a
> floating-point exception.
>      is this the current version? Are there any prerequisites
> regarding the installed toolchain (gcc,...)
>      can i use the ffigen on OSX to generate the ffi files for the
> target?
>      (up to now i didn't spend a lot of time on that, we have to get
> the software running first, but time will come...)
>

If "search" worked on the mailing list archives, I could point you
to the relevant message. where this was discussed   The short
version is that about a year ago, the GNU linker was changed to
offer a new scheme for hashing symbols; this was intended to
improve the startup time of programs that use things like the
KDE and GNOME libraries, where it may be necessary to resolve
thousands of external symbols.  The dynamic linker changed
around the same time; new versions of the dynamic linker understand
the new hash section format.  Unfortunately, older versions of
the dynamic linker don't understand the new hash section format,
do see an (empty) old section, starts hashing symbols by computing
a hash code and doing (MOD HASH-CODE NUMBER-OF-BUCKETS), and 
since NUMBER-OF-BUCKETS in the (empty) old hash section is 0,
that MOD operation gets a divide-by-zero.  (Which, from Unix's
point of view, results in a "floating point exception.)

This affected the lisp kernel in some snapshots: if I built
it on a relatively recent version of Fedora, it wouldn't work
for people running a distribution that used the old dynamic
linker.  The short-term workaround was "build the lisp kernel
yourself"; eventually, the Makefile for platforms that might
be affected by this was changed to say "if the linker offers
options related to hash-section format, use the old format".

I'm sure that the FFIGEN binaries were built on a Fedora
system.  I'm also sure that it'd be possible to hack the
Makefile (or Makefile.in) there to do the same sort of thing
(or to have autoconf detect the linker options and do it 
for us ...)  On the other hand, it takes ~20 minutes or
so to build FFIGEN from source ...

If I get the 20 minutes and remember, I'll try to replace
the linux ffigen binaries with something built on Ubuntu
or some other system that uses the old hash-section format.

>
> Ralf Stoye
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>