Taylor, thanks for responding.
> FYI, there is not much difference in auditability between the
> `portable C' version and the amd64 unix binary version -- they are
> both precompiled from sources that unfortunately do not have a
> nonincestuous bootstrapping story. The amd64 unix binary version will
> be a lot faster and generally work better.
I have installed the binary version. When I run scheme it dies with
the following message:
---
$scheme
unable to mmap executable heap -- native code will probably
failMIT/GNU Scheme running under OpenBSD
Type `^C' (control-C) followed by `H' to obtain information about interrupts.
There is no trap handler for recovery!
User requested termination after trap.
---
If I mash ^C immediately, it gives me the interrupt options. I can
then press T to get a stack trace that ends with something like:
---
{0x190524f48140} ...: [compiled-code-block 0x19052532fe00]
{0x190524f48148} ...: [compiled-code-block 0x19052532fea8]
{0x190524f48150} ...: [compiled-code-block 0x19052532ff50]
{0x190524f48158} ...: [false 0xa]
{0x190524f48160} ...: [manifest-nm-vector 0x7] (skipping)
{0x190524f481a0} ...: [vector 0x1905253304c8]
{0x190524f481a8} ...: [ENVIRONMENT 0x190525330500] (from [vector 0x107cc51b8])
{0x190524f481b0} ...: [false 0x8b]
{0x190524f481b8} ...: [manifest-nm-vector 0x63] (skipping)
{0x190524f484d8} ...: [linkage-section 0x1e]
{0x190524f484e0} ...: 2
{0x190524f484e8} ...:
>> A hardware fault has occurred within critical section "band load".
>> [signal 10 (SIGBUS), code 3]
>> Successful recovery is unlikely.
Choose one of the following actions:
D = dump core
I = terminate immediately
N = terminate normally
R = attempt recovery
Q = terminate normally
Action ->
---
If I dump core and use gdb, I get a backtrace like the following:
---
(gdb) backtrace
#0 0x00001904a982a79a in thrkill () at {standard input}:5
#1 0x00001904a98302c9 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52
#2 0x000019023e84a1fa in UX_dump_core () from /usr/local/bin/scheme
#3 0x000019023e84b2c5 in trap_handler () from /usr/local/bin/scheme
#4 0x000019023e844630 in sighnd_hardware_trap_wrapper () from
/usr/local/bin/scheme
#5 0x000019023e8440de in sighnd_hardware_trap () from /usr/local/bin/scheme
#6 <signal handler called>
#7 0x000019023e810121 in do_printing () from /usr/local/bin/scheme
#8 0x000019023e810a66 in Back_Trace () from /usr/local/bin/scheme
#9 0x000019023e82962c in debug_back_trace () from /usr/local/bin/scheme
#10 0x000019023e84596a in sighnd_interactive_wrapper () from
/usr/local/bin/scheme
#11 0x000019023e84430e in sighnd_interactive () from /usr/local/bin/scheme
#12 <signal handler called>
#13 0x000019023e817de9 in gc_scan_oldspace () from /usr/local/bin/scheme
#14 0x000019023e8139ed in load_file () from /usr/local/bin/scheme
#15 0x000019023e813dcd in Prim_band_load () from /usr/local/bin/scheme
#16 0x000019023e81e1e5 in Interpret () from /usr/local/bin/scheme
#17 0x000019023e80ef5c in main () from /usr/local/bin/scheme
---
It seems to be something in microcode/fasload.c that is causing
trouble? My /var/log/messages reports a W^X violation, but the
/usr/local partition is marked as wxallowed in fstab.
Again, any help would be appreciated.
_______________________________________________
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
