Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install fails w/ map failure on Chromebook #122

Closed
1 of 5 tasks
JohnReppy opened this issue Jul 15, 2022 · 0 comments
Closed
1 of 5 tasks

Install fails w/ map failure on Chromebook #122

JohnReppy opened this issue Jul 15, 2022 · 0 comments
Assignees
Labels
bug Something isn't working gforge bug (or feature request) ported from smlnj-gforge repository installer

Comments

@JohnReppy
Copy link
Contributor

Version

110.76

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

3.4.0

Processor

x86 (32-bit)

Component

Installation

Severity

Critical

Description of the problem

I\m getting non-recoverable errors when running binaries of sml, or
running the installer script. This is happening on an Acer C7
Chromebook running x86 Chrubuntu or Arch. Under either environment any
attempt to run sml or install.sh from the config.tgz results in the
following:

Error -- unable to map 655360 bytes, errno = 1
Fatal error -- unable to allocate memory object for BIBOP

With a binary installation (as with Ubuntu) this will be seen when
running sml at the command line. But when running the install scripts,
whether directly from the smlnj.org config.tgz or from Arch\s AUR, the
error comes at this point (discovered by enabling POSIX shell\s debug
output in the install script):

(after changing directories to /usr/local/smlnj/sml.boot.x86-unix)

/usr/local/smlnj/bin/.link-sml @SMLheap=/usr/local/smlnj/sml @SMLboot=BOOTLIST @SMLalloc=512k

And here are the errors produced:

/usr/local/smlnj/bin/.run/run.x86-linux: Error -- unable to map 655360 bytes, errno = 1
/usr/local/smlnj/bin/.run/run.x86-linux: Fatal error -- unable to allocate memory object for BIBOP

Watching the above command with strace gives the following immediately
prior to the output errors:

mmap2(NULL, 720896, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 3, 0) = -1 EPERM (Operation not permitted)

I attempted to replicate the problem using both Ubuntu and Arch
virtual machines with similar resources, but sml worked fine in both.

The rest of this description is just output from uname, /proc/cpuinfo,
and /proc/meminfo. The short of this is Linux kernel 3.4.0, dual-core
Celeron 847 @ 1.10 GHz, and 2GB DDR3 SDRAM.

========================================================================

uname -a:

Linux runciter 3.4.0 #1 SMP Thu Sep 12 16:21:05 PDT 2013 i686 GNU/Linux


cat /proc/cpuinfo:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Celeron(R) CPU 847 @ 1.10GHz
stepping : 7
microcode : 0x28
cpu MHz : 800.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 2195.08
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Celeron(R) CPU 847 @ 1.10GHz
stepping : 7
microcode : 0x28
cpu MHz : 800.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer xsave lahf_lm arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 2195.08
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:


cat /proc/meminfo:

MemTotal: 2002276 kB
MemFree: 1519772 kB
Buffers: 15280 kB
Cached: 228940 kB
SwapCached: 0 kB
Active: 229448 kB
Inactive: 220552 kB
Active(anon): 206724 kB
Inactive(anon): 64584 kB
Active(file): 22724 kB
Inactive(file): 155968 kB
Unevictable: 32 kB
Mlocked: 32 kB
HighTotal: 74504 kB
HighFree: 140 kB
LowTotal: 1927772 kB
LowFree: 1519632 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 8 kB
Writeback: 0 kB
AnonPages: 205796 kB
Mapped: 58688 kB
Shmem: 65528 kB
Slab: 17800 kB
SReclaimable: 9632 kB
SUnreclaim: 8168 kB
KernelStack: 968 kB
PageTables: 1844 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1001136 kB
Committed_AS: 752488 kB
VmallocTotal: 122880 kB
VmallocUsed: 15392 kB
VmallocChunk: 106996 kB
DirectMap4k: 12280 kB
DirectMap2M: 1949696 kB

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

tuirgin@gmail.com

Comments from smlnj-gforge

Original smlnj-gforge bug number 120

Submitted via web form by Christopher D. Walborn tuirgin@gmail.com on 2013-34-06 at 13:3400

comment by @JohnReppy on 2014-26-27 23:2600 +000 UTC

I think that the issue is probably related to some form of sandboxing being done on the chrome book. The EPERM error message means that the request for execute permission (PROT_EXEC) is not allowed. SML/NJ needs to be able to allocate memory that has execute permission since its compiler generates and executes code on the fly. I haven't been able to find any documentation for how to accomplish this in ChrUbuntu.

comment by @JohnReppy on 2014-45-28 21:4500 +000 UTC

It appears that the problem is because of the fact that /dev (and thus /dev/zero) does not allow mapping with execute permission. I have changed the runtime to use MAP_ANONYMOUS (which it should have been doing anyway) on Linux. I cannot verify that this change fixes the bug, but I'm going to mark it closed.

@JohnReppy JohnReppy added bug Something isn't working gforge bug (or feature request) ported from smlnj-gforge repository installer labels Jul 15, 2022
@JohnReppy JohnReppy self-assigned this Jul 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working gforge bug (or feature request) ported from smlnj-gforge repository installer
Projects
None yet
Development

No branches or pull requests

1 participant