From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 1D7DF7ED69 for ; Tue, 28 May 2019 13:32:26 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=jf451@cam.ac.uk; spf=Pass smtp.mailfrom=jf451@cam.ac.uk; spf=Pass smtp.helo=postmaster@ppsw-41.csi.cam.ac.uk Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jf451@cam.ac.uk) identity=pra; client-ip=131.111.8.141; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jf451@cam.ac.uk"; x-sender="jf451@cam.ac.uk"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of jf451@cam.ac.uk designates 131.111.8.141 as permitted sender) identity=mailfrom; client-ip=131.111.8.141; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jf451@cam.ac.uk"; x-sender="jf451@cam.ac.uk"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@ppsw-41.csi.cam.ac.uk designates 131.111.8.141 as permitted sender) identity=helo; client-ip=131.111.8.141; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jf451@cam.ac.uk"; x-sender="postmaster@ppsw-41.csi.cam.ac.uk"; x-conformance=sidf_compatible; x-record-type="v=spf1" IronPort-PHdr: =?us-ascii?q?9a23=3A9Bx7VBNWQTi1RTBZJuQl6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0I/j6rarrMEGX3/hxlliBBdydt6sdzbOM7uu7CSQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9HiTagfL9+Ngi6oRvRu8UZj4ZvKbs6xwfUrHdPZ+?= =?us-ascii?q?lY335jK0iJnxb76Mew/Zpj/DpVtvk86cNOUrj0crohQ7BAAzsoL2465MvwtRne?= =?us-ascii?q?VgSP/WcTUn8XkhVTHQfI6gzxU4rrvSv7sup93zSaPdHzQLspVzmu87tnRRn1gy?= =?us-ascii?q?oBKjU38nzYitZogaxcrh2uqB9xzYDUbo+LKfRxYrjQcskGSWdbRMtcTTZMDp+6?= =?us-ascii?q?YoASD+QBJ+FYr4zlqlcAqRW+Ag+sD/7vxD9SmHD227E10+QvHQrb2wEgHdwOvX?= =?us-ascii?q?vUodnoL6odTfq6zKzSwTrZc/xawyr96IvRfx0nvPqCU7Vwcc/LxkkuEQPIllqQ?= =?us-ascii?q?qY35PzOVy+QCqHKX4PZnVeKqjWMstgJ/oiC3y8sxhITFm5gZxk3Z+Slk2oo4Js?= =?us-ascii?q?e0RFN0bNK5CJddtiCXO5FrTs8/Xm1koik3xqcYtZKlfyUHzoksyQTFZPydaYeI?= =?us-ascii?q?5wruVOaPLjd8g3JoYKq/hw6p8Umu0+HxWdS43ExWoSpek9nArGwC2AbW6sSdUP?= =?us-ascii?q?Ry4l2t2SuM1wzL6+FEJ147lbbDJpI8zLM8i4AfvVneEiPrgkn7j7Waelgr9+S1?= =?us-ascii?q?8+jnZ6/ppp6YN496kAH+NaEul9S9AeQ2PQUDX3WX9P+g27L5+E31Wq9FgeEsnq?= =?us-ascii?q?nEs5DWPd4bqbKhAw9JzoYj7A6yACu839QdmXkLNVZFeBOcj4j1IFzOO/D5DfKn?= =?us-ascii?q?g1u2ijtrxvbGPqfgAprXNHTDnq3hca5460FGyQozyd5f54hTCrEEOP/zXU3xtN?= =?us-ascii?q?rfDhM+Ngy73f3nCNBh1oMGQ22PH7OZMKPKsVCW/OIvOO6MZIkPtzb5Kvgl+/7v?= =?us-ascii?q?gWY6lFISfqSk3IUbZXC3E/lpOkmVfH7hjssfHWoIvwczSO3nhESAUT5daHu/X7?= =?us-ascii?q?8w6ykjBY26F4jDQ5qhj6ad0yuhA51WZXtLCl6WHnfza4WEXu0DaCOWIsN7jjME?= =?us-ascii?q?Ur2hRok83hywsA/61qFnLvbK9S0CqJzj1dl06PPLmB0upnRICJGW2mSJCmV1hX?= =?us-ascii?q?8gRjks3ak5r1Yu5E2E1P0yofteXfJJ6vVCUk1yYZzSk7EjI9v7X0TIdZGUSwD1?= =?us-ascii?q?EZ2dHTgtQ4dpkJc1aEFnFoD610GR72+RG7YQ0oezKtkx+6PY0WL2Ip8kmX3P0e?= =?us-ascii?q?8ohB87QZkWbDH0tutE7wHWQrXxvQCBja/zLPYX1SuL/WzF0Gnc5BgFAj41ar3M?= =?us-ascii?q?WDUkXmWTrdn94RmZHae2EqtiblIHwtWDbKBDb5vghhNbR6W6NQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/EgBeG+1ch40Ib4NlghmBKAIBgU1SA?= =?us-ascii?q?QEwKI0OimIBAQaBEIl0jwuBegEIAQMBDB8QAQGEQIJhHAYBBDYEDQEDAQEEAQE?= =?us-ascii?q?CAQEDARMBAQEKCwkIKSMMgjoignAEQQEBOAQaboNmAYF2BQ8Pp0yCIIJ5AQEFg?= =?us-ascii?q?jyCdSGBTgMGgTIDAQGGeoVlgQeBEScMgjEBAYNLAoIOhTWBMQEBAaciAQYCAQK?= =?us-ascii?q?CDQNchVWMWyGCH4pmiUSTcI8egWkDgXKBAT8uGlaBToIpg1aHeoJaPgEBMY8WA?= =?us-ascii?q?QE?= X-IPAS-Result: =?us-ascii?q?A0A/EgBeG+1ch40Ib4NlghmBKAIBgU1SAQEwKI0OimIBAQa?= =?us-ascii?q?BEIl0jwuBegEIAQMBDB8QAQGEQIJhHAYBBDYEDQEDAQEEAQECAQEDARMBAQEKC?= =?us-ascii?q?wkIKSMMgjoignAEQQEBOAQaboNmAYF2BQ8Pp0yCIIJ5AQEFgjyCdSGBTgMGgTI?= =?us-ascii?q?DAQGGeoVlgQeBEScMgjEBAYNLAoIOhTWBMQEBAaciAQYCAQKCDQNchVWMWyGCH?= =?us-ascii?q?4pmiUSTcI8egWkDgXKBAT8uGlaBToIpg1aHeoJaPgEBMY8WAQE?= X-IronPort-AV: E=Sophos;i="5.60,523,1549926000"; d="scan'208,217";a="385026956" X-MGA-submission: =?us-ascii?q?MDGdQTsfE5ga22EVUVj1BhrLGx2gRBSu0tJVvb?= =?us-ascii?q?np8G4lRXFVH8COP5f8AiSvj1hdF10CaEsTMV3a70L/7ELGcVWA3YqXTQ?= =?us-ascii?q?Pt7pDQUcJ1SrXM14cT4G3PVsLa3C8GMubRCyR5DiMNw2pSY72iKbKveo?= =?us-ascii?q?WW4A0ki83aQd12c6gE3TXWIg=3D=3D?= Received: from ppsw-41.csi.cam.ac.uk ([131.111.8.141]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 May 2019 13:32:25 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cam.ac.uk; s=20180806.ppsw; h=Content-Type:Subject:To:From:Date:Message-Id:Mime-Version :Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7tc3Rd8B/r6g1NCWvQDwVeBsdd36Seh/lUEKlAQFMX4=; b=Rvy4SvsPoRxP5nIdiBRUAIbEvJ e/YKOvQAFxVr4kHXEggErhPgaiuHtqm/2Q+utt3QfaQ4XceOcNW+fUeq6V90JAIUStd59iMt71xC1 R6moaH37DmIdoaNc6Fr8Ek92wPqsUirj0p6dxru4uk7ITfHiDup52/BdQJpSnvWRaoY0=; X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:33799) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (LOGIN:jf451) (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1hVaLA-000QuC-Rj (Exim 4.91) (return-path ); Tue, 28 May 2019 12:32:24 +0100 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id E32182228E; Tue, 28 May 2019 07:32:22 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Tue, 28 May 2019 07:32:22 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvhedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedflfhonhcuhfhrvghntghhfdcuoehjfheghedusegtrghmrdgr tgdruhhkqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrih hlfhhrohhmpehojhhnohdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqkeeg keeivdehgeegqdduledtvdejieeliedqjhhfgeehudeppegtrghmrdgrtgdruhhksehfrg hsthhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 74CADE00A1; Tue, 28 May 2019 07:32:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-553-gc304556-fmstable-20190524v1 Mime-Version: 1.0 Message-Id: <8d058e9d-5293-46f1-9941-7c33fd232e04@www.fastmail.com> Date: Tue, 28 May 2019 12:32:21 +0100 From: "Jon French" To: caml-list@inria.fr Content-Type: multipart/alternative; boundary=7b3ac02e9dde4dafb07afc85558d540e X-Validation-by: jf451@cam.ac.uk Subject: [Caml-list] Only bytecode version of executable allocating huge amounts --7b3ac02e9dde4dafb07afc85558d540e Content-Type: text/plain Hi all, I'm wondering if anyone on this list might have encountered this issue before, since it's got me pretty stumped. We have an OCaml project ( https://github.com/rems-project/sail ) which tries to allocate huge amounts of memory, but only when compiled to bytecode. The native version works perfectly fine. strace for an example run ends in: > openat(AT_FDCWD, "/home/ojno/work/sail2/lib/vector_dec.sail", O_RDONLY|O_CLOEXEC) = 3 > lseek(3, 0, SEEK_CUR) = 0 > read(3, "$ifndef _VECTOR_DEC\n$define _VEC"..., 65536) = 7031 > mmap(NULL, 1965819695104, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) > brk(0x5729f32c4000) = 0x55603f2f4000 > mmap(NULL, 1965819826176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) > write(2, "Fatal error: out of memory.\n", 28Fatal error: out of memory. > ) = 28 > exit_group(2) = ? > +++ exited with 2 +++ which naturally fails since I don't have 2 TB of memory available. The exact amount of the allocation varies from input to input and even run to run, but is always that approximate size. There's no characteristic pattern of heap or stack running out of control if I turn on memory debugging info in $OCAMLRUNPARAM, just that one huge allocation. When run in ocamldebug, it also doesn't appear to be failing at a location which is sensible to be allocating such amounts of memory -- and the location also varies with the input. And on tiny inputs it doesn't seem to try and make the allocation at all. Are we actually seeing a compiler/runtime bug here? Is there something I'm missing? Thanks, Jon French Computer Laboratory University of Cambridge --7b3ac02e9dde4dafb07afc85558d540e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,

I'm wondering if anyone on this list might have enc= ountered this issue before, since it's got me pretty stumped.

We have an OCaml project ( https://github.com/rems-project/sail ) which tries to = allocate huge amounts of memory, but only when compiled to bytecode. The na= tive version works perfectly fine.

strace for = an example run ends in:

<= div>openat(AT_FDCWD, "/home/ojno/work/sail2/lib/vector_dec.sail", O_RDONLY|= O_CLOEXEC) =3D 3
lseek(3, 0, SEEK_CUR)    = ;            &n= bsp;  =3D 0
read(3, "$ifndef _VECTOR_DEC\n$define _VEC".= .., 65536) =3D 7031
mmap(NULL, 1965819695104, PROT_READ|PROT_= WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =3D -1 ENOMEM (Cannot allocate mem= ory)
brk(0x5729f32c4000)      &= nbsp;           &nbs= p;  =3D 0x55603f2f4000
mmap(NULL, 1965819826176, PROT_RE= AD|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =3D -1 ENOMEM (Cannot allo= cate memory)
write(2, "Fatal error: out of memory.\n", 28Fata= l error: out of memory.
) =3D 28
exit_group(2)&= nbsp;           &nbs= p;            &= nbsp; =3D ?
+++ exited with 2 +++
=
which naturally fails since I don't have 2 TB of memory avai= lable.

The exact amount of the allocation var= ies from input to input and even run to run, but is always that approximate= size. There's no characteristic pattern of heap or stack running out of co= ntrol if I turn on memory debugging info in $OCAMLRUNPARAM, just that one h= uge allocation. When run in ocamldebug, it also doesn't appear to be failin= g at a location which is sensible to be allocating such amounts of memory -= - and the location also varies with the input. And on tiny inputs it doesn'= t seem to try and make the allocation at all.

= Are we actually seeing a compiler/runtime bug here? Is there something I'm = missing?

Thanks,

= Jon French
Computer Laboratory
University of Ca= mbridge
= --7b3ac02e9dde4dafb07afc85558d540e--