[Openmcl-devel] Newest lx86cl64 crashes on newest RedHat
gb at clozure.com
Wed Apr 6 04:38:35 CDT 2011
2.6.18 is several years old (was released in 2006), though it looks
like the particular kernel you're using was built more recently (with
an unknown set of mystery patches.)
That particular symptom seems to have been triggered by some changes in the
Linux kernel that were introduced last summer. The short version is that when
the MAP_GROWSDOWN option was used to map stack pages, the first page in the
returned address range was unmapped. (The mmap system call isn't supposed to
return unmapped pages, but I guess the argument is that since MAP_GROWSDOWN
is a non-standard option mmap's behavior when it's present can be arbitrary.)
We stopped using the MAP_GROWSDOWN option a long time ago (early September 2010).
The two possibilities that come to mind are:
- the lx86cl64 binary that you're using is very old. This can happen if the
file's been locally modified: 'svn update' will refuse to overwrite the
file in that case. You can do:
$ cd ccl
$ svn revert lx86cl64
and if that says that it reverted the file and that fixes the problem, you owe
me US $8.
- MAP_GROWSDOWN isn't being used, but the Linux kernel that you're using returns
an unmapped page anyway. I have not seen this behavior in the kernels
distributed by current Ubuntu or Fedora releases and I don't know how that
behavior would not be a bug in mmap(). This doesn't seem very likely.
The code in question has called MapMemoryForStack(), which in turn calls mmap()
with some standard/portable options. If that returns something other than
MAP_FAILED, the address that mmap() returns is returned to create_stack(), which
then tries to to store the size of the stack in the word at that address. If
you get a bus error at that point, then I can't think of a reason for that besides
those mentioned above.
On Wed, 6 Apr 2011, Paul Meurer wrote:
> The newest (rev. 14705) lx86cl64 crashes on a recent RedHat installation on startup at create_stack().
> Has anybody else seen that, or does it work for somebody with the same versions?
> Here is the RedHat version:
> Linux version 2.6.18-238.5.1.el5 (mockbuild at x86-002.build.bos.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)) #1 SMP Mon Feb 21 05:52:39 EST 2011
> And here is the gdb output:
> Revision 14705.
> lisp at gandalf:~/lisp/ccl-1.7> gdb
> GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2)
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> (gdb) file lx86cl64
> Reading symbols from /sandisk/home/lisp/lisp/ccl-1.7/lx86cl64...done.
> (gdb) run
> Starting program: /sandisk/home/lisp/lisp/ccl-1.7/lx86cl64
> warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000
> [Thread debugging using libthread_db enabled]
> Program received signal SIGBUS, Bus error.
> create_stack (size=<value optimized out>) at ../thread_manager.c:1575
> 1575 *((size_t *)p) = size;
> (gdb) bt
> #0 create_stack (size=<value optimized out>) at ../thread_manager.c:1575
> #1 0x0000000000413ba5 in allocate_lisp_stack (useable=<value optimized out>, softsize=2412544, hardsize=7, softkind=4294967295, hardkind=4294967295, h_p=0x0,
> base_p=0x7fffffffe2d0, softp=0x7fffffffe2c0, hardp=0x7fffffffe2b8) at ../pmcl-kernel.c:226
> #2 0x0000000000413da9 in allocate_lisp_stack_area (stack_type=AREA_VSTACK, usable=0, softsize=102400, hardsize=4096, softkind=4294967295, hardkind=4294967295)
> at ../pmcl-kernel.c:282
> #3 0x000000000041e523 in new_tcr (vstack_size=2301952, tstack_size=262144) at ../thread_manager.c:1341
> #4 0x000000000041395b in main (argc=<value optimized out>, argv=0x300040000000, envp=<value optimized out>, aux=<value optimized out>) at ../pmcl-kernel.c:1907
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel