Re: [MIT-Scheme-devel] Installing on OpenBSD from portable C

[Pavan Maddamsetti]

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.