Custom Query (1030 matches)

I fetched clozurecl-1.2-rc1-freebsdx8664.tar.gz from ftp.clozure.com. Extracted it. It does not start.

FreeBSD alka-seltzer.headcraft.de 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16 01:31:10 UTC 2008     root@palmer.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
alka-seltzer 104_> ./fx86cl64
exception in foreign context
Exception occurred while executing foreign code
? for help
[2829] OpenMCL kernel debugger: b

Framepointer [#x7FFFFFFFDCC0] in unknown area.

I'm experiencing strange behavior from CCL on Linux x86. When invoking it in the normal way (ccl/scripts/ccl) as well as directly (./lx86cl lx86cl.image) I receive no output from the application. It does not respond to C-c or C-d, nor can I execute any Lisp forms.

Linux domU-12-31-39-02-6A-15 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:39:36 EST 2008 i686 athlon i386 GNU/Linux

Notes from openmcl-devel, R. Matthew Emerson:

"I tried to run the lisp on an EC2 image myself.

What seems to happen is that the lisp kernel starts up, maps in the heap image, and starts running lisp code, which pretty much immediately tries to allocate memory by taking a trap (int $0xc5 on x86 systems).

For some reason, instead of generating a SIGSEGV like we expect, the system just sort of sits there, dumbly staring at the alloc_trap in a puzzled manner.

I don't know if this a symptom of running on Xen or whether there is some other peculiarity of Amazon's EC2 set-up. I have run Clozure CL on a a Linux Xen instance before, though it was a 64-bit version."

When we save source information about a function defined via COMPILE-FILE, we usually save information about the source file and the character (or octet ?) range from which the defining form was read. (We can optionally save a string which matches the sequence of characters read form this range, but this adds to image size and is often redundant.)

If we don't save the string, we currently don't know (or have any way of knowing) whether the file has been modified since it was compiled to produce the current definitions. (If it has been modified, it's certainly reasonable to claim that source information associated with a definition may be inaccurate, possibly grossly so; in that case, we could either refuse to present it or present that source info with a disclaimer.)

Unfortuantely, I don't think that we track any information that'd enable us to detect modifications. Storing the modification date of the file might be at least somewhat reliable, but there are many scenarios (svn co ...) where the modification date will change but the contents would not, and this could unfortunately yield many false-positive claims of modification.)

I wonder if it's possible/practical to generate some sort of checksum for the (octets? characters?) in the range associated with a definition, and to have DISASSEMBLE (and error-reporting functions, and other things) compare this checksum to what would be obtained by reading the same sequence from the file ?

There may be a better way of doing this, but it'd be good to be able to distinguish between "source text in which we have very high confidence" and "stuff that was in the recorded file position in the relatively recent past."