[Openmcl-devel] Build failure (Linux x86-64)

[Gary Byers]

I wish that the search button worked in the mail archives ...

Linux 2.6.23 kernels introduced the notion of a "vdso", which is a special
type of shared library which (as I understand it) helps other shared libraries
communicate with the kernel; this vdso ordinarily gets loaded into the
address space of every process.

The vdso links itself into the data structures that describe the
shared libraries in the process's address space.  Some field in one of
those data structures can be used as either an absolute address or a
relative offset to some other object's address; "real" Linux shared
libraries use the field as an absolute address, but (possibly because
it's loaded via a different mechanism) the vdso uses the field as
a (negative) offset.

When the lisp starts up, one of the first things that it does is to
(re-)initialize its notion of what shared libraries are available.
It encounters the vdso, misinterprets the negative offset as an absolute
address, and segfaults.  I'm pretty sure that that's what you're seeing.

This is fixed in CVS/SVN, but the 070722 binaries are getting pretty long
in the tooth.  (New release soon!  Honest!)

The general workaround is:

a) do something to suppress the vdso loading (see below)
b) run the 070722 image, update from CVS/SVN, build something more current
c) re-enable vdso loading if you want to.

There are apparently two ways to suppress vdso loading:

1) As root, do:

shell# sysctl -w kernel.vdso=0

I believe that you should be able to run and update 070722 after doing
this.

2) Add "vdso=0" to the kernel's boot parameters.

If you use the "grub" bootloader, you can you can press a few keys and
edit the kernel options just before the kernel boots.  There are other
ways of doing this; the "edit just before booting" approach might be
simplest.

Yes, this is all a PITA.  Sorry.

On Fri, 4 Apr 2008, Jeronimo Pellegrini wrote:

> Hello!
>
> On Fri, Apr 04, 2008 at 03:58:34PM -0400, Osei Poku wrote:
>> Did you look at
>> http://clozure.com/pipermail/openmcl-devel/2008-March/008070.html and the
>> surrounding thread?
>
> Yes, but I thought it was a difefrent issue.
>
>> I didn't get the same error as you, however, I suggest you try an
>> earlier tarball like "070722".
>
> I tried that, but 070722 doesn't work:
>
> ccl-070722 $ ./lx86cl64
> Unhandled exception 11 at 0x30004006dfc4, context->regs at
> #x7fff46714478
> ? for help
> [14236] OpenMCL kernel debugger:
> ccl-070722 $
>
> That was with a freshly unpacked tarball of 070722...
>
> J.
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>