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: Sat, 7 Dec 2013 22:29:48 +0200 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b873a10c70a3804ecf79fb7 X-Trace: ger.gmane.org 1386448213 25578 80.91.229.3 (7 Dec 2013 20:30:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Dec 2013 20:30: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 Sat Dec 07 21:30: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 1VpOW2-0006b4-Dm for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Dec 2013 21:30:18 +0100 Original-Received: from localhost ([::1]:37300 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpOW1-0002EL-U6 for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Dec 2013 15:30:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpOVu-0002EB-9z for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2013 15:30:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VpOVp-0003do-AY for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2013 15:30:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpOVp-0003dA-7X for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2013 15:30:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VpOVn-0002PK-VO for bug-gnu-emacs@gnu.org; Sat, 07 Dec 2013 15:30:04 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: emacs user Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Dec 2013 20:30:03 +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.13864481959210 (code B ref 16039); Sat, 07 Dec 2013 20:30:03 +0000 Original-Received: (at 16039) by debbugs.gnu.org; 7 Dec 2013 20:29:55 +0000 Original-Received: from localhost ([127.0.0.1]:36935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VpOVe-0002OU-5E for submit@debbugs.gnu.org; Sat, 07 Dec 2013 15:29:54 -0500 Original-Received: from mail-we0-f174.google.com ([74.125.82.174]:63830) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VpOVZ-0002OJ-Es for 16039@debbugs.gnu.org; Sat, 07 Dec 2013 15:29:51 -0500 Original-Received: by mail-we0-f174.google.com with SMTP id q58so1961611wes.5 for <16039@debbugs.gnu.org>; Sat, 07 Dec 2013 12:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=HItmoGsASKQWyLyV7VmcGFNabMxQsQvy9lKnGdK1q24=; b=zbZkC3CdGtkSjEcXh5LJEMwI/a2fpnQOrQcjpORKXFxjAp0gdcubLdlWhR/S58Ashv Yn9JTrEWfQlAsrpRkc+44ZYjtJ8lvX2n5XXLNJCQbe70tg/2/9VtW7IcScSXucJ7GxIT pQXUh912D79uRaGcwpaVMrVVJ85cnE0Qfnqq1nZUHJhaIS+JKkLmgeBigTg6eMeL40XO N4FSE+jUPlsGqIFdo3ktUDRaG7YufKw6xjCEyQHE4Dv16CRN5/PQlaVf4KUiHZE17/C/ UoACGLqMYYG2uUb6qPlHSWYTuXbz5AotYnMSx0UqyYZwUx7xz7r1MC6n3Dxg2IVd2O26 hHcw== X-Received: by 10.194.202.230 with SMTP id kl6mr8983431wjc.9.1386448188540; Sat, 07 Dec 2013 12:29:48 -0800 (PST) Original-Received: by 10.216.47.129 with HTTP; Sat, 7 Dec 2013 12:29:48 -0800 (PST) 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:81608 Archived-At: --047d7b873a10c70a3804ecf79fb7 Content-Type: text/plain; charset=ISO-8859-1 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 >> > > --047d7b873a10c70a3804ecf79fb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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


--047d7b873a10c70a3804ecf79fb7--