From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: emacs user Newsgroups: gmane.emacs.bugs Subject: bug#16039: repeated emacs crashes (in GC?) Date: Sun, 15 Dec 2013 19:17:20 +0200 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c228d22bdd6904ed95de15 X-Trace: ger.gmane.org 1387127893 16052 80.91.229.3 (15 Dec 2013 17:18:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Dec 2013 17:18:13 +0000 (UTC) Cc: 16039@debbugs.gnu.org To: YAMAMOTO Mitsuharu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 15 18:18:18 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VsFKb-0000t5-Kv for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Dec 2013 18:18:17 +0100 Original-Received: from localhost ([::1]:51821 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsFKb-0003QC-65 for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Dec 2013 12:18:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34967) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsFKS-0003Jh-DS for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2013 12:18:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VsFKN-000812-2w for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2013 12:18:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsFKM-00080x-Vd for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2013 12:18:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VsFKM-0008WF-AC for bug-gnu-emacs@gnu.org; Sun, 15 Dec 2013 12:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: emacs user Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Dec 2013 17:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16039 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16039-submit@debbugs.gnu.org id=B16039.138712784532689 (code B ref 16039); Sun, 15 Dec 2013 17:18:02 +0000 Original-Received: (at 16039) by debbugs.gnu.org; 15 Dec 2013 17:17:25 +0000 Original-Received: from localhost ([127.0.0.1]:51908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VsFJj-0008V9-Ug for submit@debbugs.gnu.org; Sun, 15 Dec 2013 12:17:24 -0500 Original-Received: from mail-wi0-f181.google.com ([209.85.212.181]:43626) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VsFJh-0008V0-3K for 16039@debbugs.gnu.org; Sun, 15 Dec 2013 12:17:22 -0500 Original-Received: by mail-wi0-f181.google.com with SMTP id hq4so1193218wib.8 for <16039@debbugs.gnu.org>; Sun, 15 Dec 2013 09:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZIQJWmjCviqMnyw6LB5jfptxPAF1E3hZOudIv9gmAk0=; b=f7Ud1/SgQSYTKu3FD2V9U4RmfTvvIGgbw2HELywmihSjuQOZEFk5Wl8x7XSK+fB7UA y929h0y6PfYIy6Fnl2DiZeNaw0llPcXcAamIHC6KSFLazgWM+y+l8CtOiwGv0gY8wQbM 5A1WMLZyFeaGtt4KQDf84THYsBFG6fhBQ4NAu1qe5k1OVeRM+BrKVOTwryE9az80T9K5 9kWM5q8EkUkNmGkJHrKVgNe1PXe3xMV/DlzRekBUkpN+EsRmEvZZSCPh9pEui0kOsfVg fRKPjxCJpruN3ROTRlBOkPFa1CRAmP6jVeAFyYbaDwC1mL2k3NClbKItsWQlFD1nlZ8D RRbw== X-Received: by 10.180.39.177 with SMTP id q17mr10615338wik.16.1387127840167; Sun, 15 Dec 2013 09:17:20 -0800 (PST) Original-Received: by 10.216.47.129 with HTTP; Sun, 15 Dec 2013 09:17:20 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:82018 Archived-At: --001a11c228d22bdd6904ed95de15 Content-Type: text/plain; charset=ISO-8859-1 Dear Eli and Mitsuharu, Please let me know if there is anything else I can do, test patches or such. again, Emacs just does not ever crash for me after the change mentioned below, a great relief. E On Sat, Dec 7, 2013 at 10:29 PM, emacs user wrote: > so after running the same emacs session for 72 hours, during which I used > vm many times and emacs used a total of 1.5 CPU hours, I think it is safe > to say that this problem that caused frequent crashes is fixed by the > increase in newlim as specified below. I hope something like this can be > implemented in the emacs development version. Thanks for your help, best, > E > > > On Thu, Dec 5, 2013 at 8:54 AM, emacs user wrote: > >> I managed to compile your mac port and inserted: >> >> newlim = (re_max_failures * ratio + 200000)*2; >> >> will let you know in a few days if I still see crashes. >> >> >> On Thu, Dec 5, 2013 at 2:35 AM, YAMAMOTO Mitsuharu < >> mituharu@math.s.chiba-u.ac.jp> wrote: >> >>> >>>>> On Wed, 04 Dec 2013 10:48:11 +0900, YAMAMOTO Mitsuharu < >>> mituharu@math.s.chiba-u.ac.jp> said: >>> >>> >>> Having 136 thousand frames during GC is not unheard of. >>> >>> >> (/ 8720000.0 (* 136 1000)) >>> >> 64.11764705882354 >>> >>> >> If each frame consumes more than 64 bytes, then it will use up >>> >> 8720000B stack space. >>> >>> > FWIW, the default compiler for Xcode 4.0.2 on Mac OS X 10.6 with the >>> > -O2 option seems to consume 64 bytes for each mark_object frame: >>> >>> > i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) >>> (dot 3) >>> >>> > _mark_object: >>> > 00000000000008a0 pushq %rbp >>> > 00000000000008a1 movq %rsp, %rbp >>> > 00000000000008a4 movq %rbx, 0xffffffffffffffd8(%rbp) >>> > 00000000000008a8 movq %r12, 0xffffffffffffffe0(%rbp) >>> > 00000000000008ac movq %r13, 0xffffffffffffffe8(%rbp) >>> > 00000000000008b0 movq %r14, 0xfffffffffffffff0(%rbp) >>> > 00000000000008b4 movq %r15, 0xfffffffffffffff8(%rbp) >>> > 00000000000008b8 subq $0x40, %rsp >>> >>> > And the one for Xcode 5.0.2 on OS X 10.9 with -O4 does 24 bytes: >>> >>> > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> > _mark_object: >>> > 0000000000005c70 pushq %rbp >>> > 0000000000005c71 movq %rsp, %rbp >>> > 0000000000005c74 pushq %r15 >>> > 0000000000005c76 pushq %r14 >>> > 0000000000005c78 pushq %r13 >>> > 0000000000005c7a pushq %r12 >>> > 0000000000005c7c pushq %rbx >>> > 0000000000005c7d subq $0x18, %rsp >>> >>> I forgot to count the pushq instructions. The correct value would be >>> 72 bytes for each mark_object frame in both cases. >>> >>> YAMAMOTO Mitsuharu >>> mituharu@math.s.chiba-u.ac.jp >>> >> >> > --001a11c228d22bdd6904ed95de15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Eli and Mitsuharu, Please let me know if there is any= thing else I can do, test patches or such. =A0again, Emacs just does not ev= er crash for me after the change mentioned below, a great relief. =A0E


On Sat, Dec 7, 2013 at 10:29 PM, emacs u= ser <user.emacs@gmail.com> wrote:
so after running the same emacs session for 72 hours, duri= ng which I used vm many times and emacs used a total of 1.5 CPU hours, I th= ink it is safe to say that this problem that caused frequent crashes is fix= ed by the increase in=A0newlim=A0as specified below. I hope something like = this can be implemented in the emacs development version. =A0 Thanks for yo= ur help,=A0best, E


On Thu, Dec 5= , 2013 at 8:54 AM, emacs user <user.emacs@gmail.com> wrot= e:
I managed to compile your mac port and in= serted:

=A0 =A0 =A0 newlim =3D (re_max_failures * ratio + 20000= 0)*2;

will let you know in a few days if I s= till see crashes.


On Thu,= Dec 5, 2013 at 2:35 AM, YAMAMOTO Mitsuharu <mituharu@math.s= .chiba-u.ac.jp> wrote:
>>>>> On Wed, 04 Dec 2013 10:48:11 +0900, Y= AMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>> Having 136 thousand frames during GC is not unheard of.

>> (/ 8720000.0 (* 136 1000))
>> 64.11764705882354

>> If each frame consumes more than 64 bytes, then it will use up
>> 8720000B stack space.

> FWIW, the default compiler for Xcode 4.0.2 on Mac OS X 10.6 with the > -O2 option seems to consume 64 bytes for each mark_object frame:

> =A0 i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) = (dot 3)

> =A0 _mark_object:
> =A0 00000000000008a0 =A0 =A0pushq =A0 %rbp
> =A0 00000000000008a1 =A0 =A0movq =A0 =A0%rsp, %rbp
> =A0 00000000000008a4 =A0 =A0movq =A0 =A0%rbx, 0xffffffffffffffd8(%rbp)=
> =A0 00000000000008a8 =A0 =A0movq =A0 =A0%r12, 0xffffffffffffffe0(%rbp)=
> =A0 00000000000008ac =A0 =A0movq =A0 =A0%r13, 0xffffffffffffffe8(%rbp)=
> =A0 00000000000008b0 =A0 =A0movq =A0 =A0%r14, 0xfffffffffffffff0(%rbp)=
> =A0 00000000000008b4 =A0 =A0movq =A0 =A0%r15, 0xfffffffffffffff8(%rbp)=
> =A0 00000000000008b8 =A0 =A0subq =A0 =A0$0x40, %rsp

> And the one for Xcode 5.0.2 on OS X 10.9 with -O4 does 24 bytes:

> =A0 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)

> =A0 _mark_object:
> =A0 0000000000005c70 =A0 =A0pushq =A0 %rbp
> =A0 0000000000005c71 =A0 =A0movq =A0 =A0%rsp, %rbp
> =A0 0000000000005c74 =A0 =A0pushq =A0 %r15
> =A0 0000000000005c76 =A0 =A0pushq =A0 %r14
> =A0 0000000000005c78 =A0 =A0pushq =A0 %r13
> =A0 0000000000005c7a =A0 =A0pushq =A0 %r12
> =A0 0000000000005c7c =A0 =A0pushq =A0 %rbx
> =A0 0000000000005c7d =A0 =A0subq =A0 =A0$0x18, %rsp

I forgot to count the pushq instructions. =A0The correct value would be
72 bytes for each mark_object frame in both cases.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= YAMAMOTO Mitsuharu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mituharu@math.s.chi= ba-u.ac.jp



--001a11c228d22bdd6904ed95de15--