X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:from:date:message-id:subject:to
	:content-type; q=dns; s=default; b=JbFQrz1SZJigs3HKFFXZYgRqtfs0d
	T7RGclBtUwc3O3LaVWngQ7R4J4RKlWYcPzqVvAvWM3CGIQGkntSIVzJDjfyXeqO0
	bcdoColfmRqlSUg5d51HLWvU5ufd4zbz+3NP+AD8g6EghyZnUIU+KqrLWT0iUdWN
	EVvoA4U0wO5soM=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:from:date:message-id:subject:to
	:content-type; s=default; bh=8nZzOoen1t2j1pqy62KTj9PtrWI=; b=I08
	k1wkKKFhZE8NMEV5ngdRGFd7ForgSvbLanFCN41zdHLRwiJ/ijreB6XUeZOex9x8
	E8GxLHdQe7rv9OpyjkrojHlRsynhVsWsj+05RB664lxwHzDEwwID0YcYDyBPUw++
	a8A8df0HHY6F1FRGY6CwbE695hw91/YdQGNPBDp0=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=Pro, unlimited, DONT, DON'T
X-HELO:	fe3.lbl.gov
X-Ironport-SBRS:	2.7
X-IronPort-Anti-Spam-Filtered:	true
X-IronPort-Anti-Spam-Result:	=?us-ascii?q?A2FwAgAMYd1Yf8bYVdFdHgYMGQYMgwKCH?= =?us-ascii?q?INbiwSTQwGSbYIOiVUHPxgBAQEBAQEBAQEBAQIQAQEJCwsIJjGCMyKCaksxDwI?= =?us-ascii?q?mAiQSAQUBDgEuE4dogggFnX+DRD+MA4ImiwcJAQh5jmMJZoI6gl8BBJYYhlKBV?= =?us-ascii?q?ZB7ikyGa5IlFB+BFR+BBDocCxQmUBgGhDgggX+ILII8AQEB?=
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jjkbxOeFaZ0gqC4OXfeqtAFAhrp7JmcZjHgTUxBvJ1E=; b=YTVF0ZyZLZiyj2pXLRAseZVf/lTUct6GPsI7McqrgWQ237/4gM0oOPS9hyXnfQzKHH D4WisPnzq0LX5J4bH6sQOPzOdVM2oyBEITqewpUcSAjcmyUkBwrQPSEFWy40N4+riUzO 7K+hFwxYPkrrDg79YRHJb8hbXOi7dpd/uf4yu/mOcOt6z9R00UIEYT0mcLmBnnBj46N+ q0+S1Bg4FU5fNp5cK/9cv5+Tefq5U7mKf/15G7dErHnCNo2pY7bKfprn3OaEPCrDFFAi lQy2I2BIDP4wyp4XhYQQKq9Z/AidsQU7r5vgJJzeGK5CmjatXFkj3KrJHiphCfPKgzIt V5uQ==
X-Gm-Message-State:	AFeK/H2Gp1dmxjfgt3Vq4bZxmTfLjl39IRydrptcolcCCgPaXl++3C4sZi3L/KG7Gj1UIjjc8FLqqIvD7BQA3jVKnpLy/1f/UDYiBaloRehD1gePxrXBlkl4NIdO1PyyrBC6tA==
X-Received:	by 10.55.74.143 with SMTP id x137mr1469902qka.17.1490903536572; Thu, 30 Mar 2017 12:52:16 -0700 (PDT)
X-Received:	by 10.55.74.143 with SMTP id x137mr1469883qka.17.1490903536336; Thu, 30 Mar 2017 12:52:16 -0700 (PDT)
X-Received:	by 10.200.38.206 with SMTP id 14mr1684294qtp.62.1490903534419; Thu, 30 Mar 2017 12:52:14 -0700 (PDT)
MIME-Version:	1.0
From:	Dan Bonachea <dobonachea AT lbl DOT gov>
Date:	Thu, 30 Mar 2017 15:51:34 -0400
X-Gmail-Original-Message-ID:	<CAJTO8-ZYz-v9YVWsv5JS4DUXhapHfgNOzUxAnHw7C_7eS17hJg AT mail DOT gmail DOT com>
Message-ID:	<CAJTO8-ZYz-v9YVWsv5JS4DUXhapHfgNOzUxAnHw7C_7eS17hJg@mail.gmail.com>
Subject:	How to ulimit virtual memory on Cygwin-64 processes?
To:	cygwin AT cygwin DOT com

Is there a way to get ulimit-style virtual memory limit enforcement on
64-bit Cygwin processes?

I'm a programmer and occasionally I have a bug that sends a process
into a memory-grabbing tail-spin. On 32-bit Cygwin, such a runaway
process gets stopped cold at 4GB VM (and usually crashes), but 4GB is
well short of the physical memory on my 64-bit windows system so this
doesn't affect my system stability.

However a similar runaway process on 64-bit Cygwin is easily capable
of grabbing nearly all of the memory on my system, which can lead to
Very Bad Things - ie unrelated user processes start crashing, desktop
window manager disappears, and the system slows to a crawl or freezes
entirely - making it difficult or impossible to kill the run-away.
Several times now I've had to hard power-cycle to recover from such a
Cygwin-64 runaway memory-grabbing process, and have lost some data as
a result.

You can replicate this behavior with a very simple program: (however I
DON'T recommend running this)

#include <stdlib.h>
#include <stdio.h>

int main() {
  printf("WARNING: I'm stealing all your memory, hit control-c to
cancel!!!\n");fflush(0);
  while(1) malloc(1e6);
  return 0;
}

The traditional POSIX solution to this problem is setrlimit() aka bash
ulimit, but that does not appear to be implemented in Cygwin 2.7.0:

$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 8
stack size              (kbytes, -s) 2036
cpu time               (seconds, -t) unlimited
max user processes              (-u) 256
virtual memory          (kbytes, -v) unlimited

$ ulimit -v 1048576
bash: ulimit: virtual memory: cannot modify limit: Invalid argument

Is there any hidden setting or other way to enforce a reasonable VM /
heap memory / page commit limit on 64-bit Cygwin processes (or even
all windows processes) via some other mechanism? I'm running Windows 7
Pro.

I've searched the Cygwin mailing list archives, user guide, FAQ, and
Google and not found a suitable answer. I've tried the peflags utility
mentioned in the Cygwin user guide, but that doesn't seem capable of
doing what I need, even for a single executable (although ideally I
want to enforce a system-wide limit).

Thanks for your consideration.

-Dan Bonachea

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -