From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10378 invoked by alias); 5 Jan 2014 21:33:53 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32235 Received: (qmail 18403 invoked from network); 5 Jan 2014 21:33:48 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=C3BFi72fEwykLl4X+Bc79wsKKhC6/PxL3JdMVvdlaoA=; b=Fgp/O1OB9h0pI+DgOaH/3jwAqxSftfW0yMhFwiRRu3JeOWYmT2FQLuYIFmhnBtT2dZ lbAqq4IhfKFRHolBtFqNFNwpWL9khs30PGtMOys7TKaciQUzVZe8tVm/5nAqKB+O318/ 00krwqIOGR43VAtNjIqM6jZhZ/YWOhycWjoerFDt7LE68h8zoBHM9MRWBhPWgbhEZf7u LpqrwNhN2AZMUsi8q6K+ohpvpdsneo/ajfoVLjhfhqVkKVYKxp+YdsSXJOU/o32HtC9a SZv3sKf3DAtFdEq9Nror4KonUK7s2U08+eHyGx7ptwKIgYlOHXkw86uLjoj+snY+gb6g /lwA== X-Gm-Message-State: ALoCoQnwpPaJIoGKxsMpKGSwPbdIHFaEjBI1CmkIcS/qcBmYt8Rk40zWrhtojSjMHy8cpiRrualr X-Received: by 10.194.175.133 with SMTP id ca5mr65737917wjc.19.1388957625615; Sun, 05 Jan 2014 13:33:45 -0800 (PST) X-ProxyUser-IP: 86.6.157.246 Date: Sun, 5 Jan 2014 21:33:41 +0000 From: Peter Stephenson To: Zsh Hackers' List Subject: Re: Segmentation Fault on Stack Overflow Message-ID: <20140105213341.71d16903@pws-pc.ntlworld.com> In-Reply-To: <20140105175831.4640d8a5@pws-pc.ntlworld.com> References: <3540501074823477909@gmail297201516> <87d2k8y6wn.fsf@ft.bewatermyfriend.org> <878uuwy0vk.fsf@ft.bewatermyfriend.org> <20140105175831.4640d8a5@pws-pc.ntlworld.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 5 Jan 2014 17:58:31 +0000 Peter Stephenson wrote: > It might be possible to do a little better by querying some of the > memory-related limits (I would guess available stack space is the key > one, but some investigation will be necessary) to see if one of the > limits is getting short and aborting function calls in a handlable > fashion at that level. Unhelpfully, limits (from getrlimit()) and > current usage (from getrusage()) don't seem to map cleanly onto one > another, and this is all rather system-specific, so this doesn't look > like a trivial project. What's more, on Linux the resources useful here aren't actually reported by getrusage() at the moment. The best I've found with a bit of poking around locally (I might do better online, but I might as well ask here first) is /proc/$$/status. This is obviously completely system specific and quite possible specific to certain kernel versions. The code below does seem to do roughly what I want (at the moment it reports the limits and usage rather than checking the values) but I can't help thinking I'm missing something. It's going to be hard to get something of general use out of this sort of thing. { struct rlimit rlimit; int found = 0; long usage, limit; char buffer[256]; FILE *sfile; sprintf(buffer, "/proc/%d/status", getpid()); sfile = fopen(buffer, "r"); if (sfile) { while (fgets(buffer, 256, sfile)) { if (!strncmp(buffer, "VmStk:", 6) && getrlimit(RLIMIT_STACK, &rlimit) == 0) { const char *ptr = buffer + 6; while (!isdigit(*ptr)) ptr++; usage = atol(ptr); limit = rlimit.rlim_cur == (rlim_t)-1 ? rlimit.rlim_max : rlimit.rlim_cur; fprintf(stderr, "stack: limit = %ld, usage = %ld\n", limit, usage * 1024); found++; } else if (!strncmp(buffer, "VmData:", 7) && getrlimit(RLIMIT_DATA, &rlimit) == 0) { const char *ptr = buffer + 7; while (!isdigit(*ptr)) ptr++; usage = atol(ptr); limit = rlimit.rlim_cur == (rlim_t)-1 ? rlimit.rlim_max : rlimit.rlim_cur; fprintf(stderr, "stack: limit = %ld, usage = %ld\n", limit, usage * 1024); found++; } if (found == 2) break; } fflush(stderr); fclose(sfile); } } pws