You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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.
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.
The text was updated successfully, but these errors were encountered:
Version
110.76
Operating System
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:
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)
And here are the errors produced:
Watching the above command with strace gives the following immediately
prior to the output errors:
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.
The text was updated successfully, but these errors were encountered: