This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 445545 - ocamlc fails trying to allocate 34 GB of RAM
ocamlc fails trying to allocate 34 GB of RAM
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: ocaml (Show other bugs)
8
athlon Linux
low Severity high
: ---
: ---
Assigned To: Richard W.M. Jones
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 438486 441685 454384
  Show dependency treegraph
 
Reported: 2008-05-07 10:50 EDT by Radzevich Belevich
Modified: 2012-11-15 13:47 EST (History)
1 user (show)

See Also:
Fixed In Version: ocaml-3.10.1-3.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 877128 (view as bug list)
Environment:
Last Closed: 2008-07-13 16:32:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
ocaml-3.10.1-map32bit.patch (805 bytes, patch)
2008-05-08 07:09 EDT, Richard W.M. Jones
no flags Details | Diff

  None (edit)
Description Radzevich Belevich 2008-05-07 10:50:16 EDT
Description of problem: 

x84_84 arch

"ocamlc" could not compile my modules: Exception Out_of_memory

I'am could not compile ocaml 3.10.1 and 3.10.2 from source: 
  Exception Out_of_memory

From cvs HEAD ocaml 3.11d+dev12 compiled successfully.
Comment 1 Richard W.M. Jones 2008-05-07 11:00:13 EDT
I've not seen this and I routinely compile OCaml modules & OCaml itself
on x86-64.

Can you give the precise versions of the Fedora ocaml packages you're
using please.
Comment 2 Radzevich Belevich 2008-05-07 11:53:38 EDT
[serp@serp pp]$ cat /etc/redhat-release 
Fedora release 9 (Sulphur)

[serp@serp pp]$ uname -a
Linux serp.office.stork.ru 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT
2008 x86_64 x86_64 x86_64 GNU/Linux

[serp@serp pp]$ rpm -qa ocaml*
ocaml-pcre-5.13.0-2.fc9.x86_64
ocaml-findlib-devel-1.2.1-2.fc9.i386
ocaml-camlp4-3.10.1-2.fc9.x86_64
ocaml-findlib-1.2.1-2.fc9.x86_64
ocaml-3.10.1-2.fc9.x86_64
ocaml-camlp4-devel-3.10.1-2.fc9.x86_64
ocaml-runtime-3.10.1-2.fc9.x86_64
ocaml-extlib-1.5.1-2.fc9.x86_64

[serp@serp pp]$ cat log.ml 

open Camlp4.PreCast;
open Syntax;


value insert_mname_mline _loc f = <:expr<Log.$lid:f$ $str:Loc.file_name  _loc$
$`int:Loc.start_line _loc$>>; 

EXTEND Gram
  GLOBAL: expr;
    
    expr: 
      [ 
        [ "Log"; "."; f = [ `LIDENT ("e"|"d"|"w" as f) -> f] ->
insert_mname_mline _loc f ]
      ];
  END;

[serp@serp pp]$ /usr/bin/ocamlc.opt -c -I +camlp4 -pp camlp4rf log.ml -o log.cmo
Fatal error: out of memory.

[serp@serp pp]$ /usr/bin/ocamlc.opt -c -I +camlp4 -pp camlp4rf log.ml -o log.cmo
Fatal error: exception Out_of_memory
Raised at file "", line 0, characters 0-0
Called from file "arg.ml", line 211, characters 4-32

[serp@serp pp]$ /usr/bin/ocamlc.opt -c -I +camlp4 -pp camlp4rf log.ml -o log.cmo
[serp@serp pp]$ 
Comment 3 Richard W.M. Jones 2008-05-07 12:16:09 EDT
First of all I can't reproduce this on either my i386 & x86-64 machines
with our ocaml-3.10.1-2 package.  They all compile log.ml with the command
shown without any error.

Also I don't quite understand the commands you show above.  Do you mean
that when you run the ocamlc.opt command three times, you get three
different outputs?  Or are you running this on different machines or
modifying the input in some manner?
Comment 4 Richard W.M. Jones 2008-05-07 12:20:28 EDT
Also, can you do:

ulimit -a
free -m

Just need to check there are no artificial limits in your setup.
Comment 5 Radzevich Belevich 2008-05-07 12:29:43 EDT
Yes, I run this command three time in a row, and get three different outputs.
Last it's compiled successfully :-)
But three it's not a regularity. Sometime it's success immediately, but
sometimes three or more.
Comment 6 Radzevich Belevich 2008-05-07 12:35:35 EDT
[serp@serp pp]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 8191
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

[serp@serp pp]$ free -m
             total       used       free     shared    buffers     cached
Mem:          1004        929         74          0         47        407
-/+ buffers/cache:        474        529
Swap:         1919          0       1919
==============================================

On i386 mashine, all ok. 
On ocaml 3.11+dev12 on this mashine (compiled from source), all ok.
But ocaml 3.10.2 compilation has this problem.
Comment 7 Richard W.M. Jones 2008-05-07 12:52:39 EDT
Yes, you're right - I can reproduce this if I run the
ocamlc.opt command often enough, and in fact I've seen
this bug before.

Bug 438486 ocaml-camomile doesn't build on ppc64 (even in Rawhide)

It's almost exactly the same symtoms too: ocamlc.opt tries
to allocate 34 GB [sic] of RAM and obviously fails.  It does this
non-deterministically.

Example from the strace:

mmap(NULL, 34289692672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= -1 ENOMEM (Cannot allocate memory)
Comment 8 Richard W.M. Jones 2008-05-07 13:30:07 EDT
A bit of informal testing seems to indicate this is a Fedora-specific
problem, in that it doesn't appear to occur on Debian.

I've posted about this issue on caml-list.

Thanks for the small reproducer.  Hopefully someone on caml-list will
have some more insight, if not I'll take a closer look over the next
few days.

Reassigning the BZ to me, I'm sure gemi won't mind :-)
Comment 9 Richard W.M. Jones 2008-05-08 06:52:09 EDT
I've tracked down the problem and come up with two possible solutions.
My reasoning is contained in this thread in more detail:

http://caml.inria.fr/pub/ml-archives/caml-list/2008/05/f03aa82c55e7dfcfb409536a28fcdedd.en.html

The problem is essentially that Fedora mmap returns high memory addresses
and the way the OCaml runtime is constructed, this is unexpected.  OCaml runtime
tries to construct a linear page table, an array tracking which pages are contained
in the OCaml heap and which are regular pages (eg. external mallocs).  This
method doesn't work when pages can be present at very high memory
addresses (or at least, it would work if the page table could be extended
to 34 GB, but it can't be!)

There are two possible solutions:

(1) Easy hack but x86-64 only: Pass the MAP_32BIT flag to mmap.  This
causes mmap to return memory addresses below 2 GB, and fixes the
problem.  However (a) this is only available on x86-64 (not, eg, ppc64
where we also have the problem).  (b) This limits the OCaml runtime to
quite a small maximum heap, probably 1 or 2 GB max.

(2) Difficult: In OCaml 3.11, the linear page table stuff has been completely
rewritten to use a hash table, to get around this problem.  We could in
theory backport this to OCaml 3.10, but honestly the patch is huge and
changes large amounts of the runtime, and I have little confidence I
could do this backport correctly.

I guess there is a third possibility which is to find out why mmap in
Fedora behaves so differently from mmap in, say, Debian.

I'll post a patch for (1) in a moment once I've done a bit more testing.
Comment 10 Richard W.M. Jones 2008-05-08 07:09:10 EDT
Created attachment 304848 [details]
ocaml-3.10.1-map32bit.patch

Patch to pass MAP_32BIT to mmap.

Confirmed that this fixes the original reported problem
on x86-64 / F-9.
Comment 11 Stephen Warren 2008-07-10 12:54:07 EDT
See also 454384; a request for a backport of this fix to F8.
Comment 12 Richard W.M. Jones 2008-07-13 16:29:58 EDT
Reopening, assigning to F-8.
Comment 13 Richard W.M. Jones 2008-07-13 16:32:13 EDT
Ooops - didn't see that we also have bug 454384.  Closing again - I'm
going to fix that one now.

Note You need to log in before you can comment on or make changes to this bug.