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: Thu, 5 Dec 2013 08:54:13 +0200 Message-ID: References: <83k3fl53fy.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e013c62205025aa04ecc3ffd0 X-Trace: ger.gmane.org 1386226515 17849 80.91.229.3 (5 Dec 2013 06:55:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Dec 2013 06:55:15 +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 Thu Dec 05 07:55: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 1VoSqD-0003eQ-Tr for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Dec 2013 07:55:18 +0100 Original-Received: from localhost ([::1]:52035 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoSqD-0002TA-Je for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Dec 2013 01:55:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoSq6-0002Qi-0k for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2013 01:55:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VoSpz-0008OR-2c for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2013 01:55:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VoSpz-0008O9-0C for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2013 01:55:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VoSpy-0001dP-A1 for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2013 01:55: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: Thu, 05 Dec 2013 06:55: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.13862264596225 (code B ref 16039); Thu, 05 Dec 2013 06:55:02 +0000 Original-Received: (at 16039) by debbugs.gnu.org; 5 Dec 2013 06:54:19 +0000 Original-Received: from localhost ([127.0.0.1]:58846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoSpF-0001cK-ST for submit@debbugs.gnu.org; Thu, 05 Dec 2013 01:54:18 -0500 Original-Received: from mail-wg0-f52.google.com ([74.125.82.52]:53664) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoSpC-0001cA-0q for 16039@debbugs.gnu.org; Thu, 05 Dec 2013 01:54:15 -0500 Original-Received: by mail-wg0-f52.google.com with SMTP id x13so16064683wgg.31 for <16039@debbugs.gnu.org>; Wed, 04 Dec 2013 22:54:13 -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=d/tHJqbz13hyUKRkL+d6KpHPnOFUauuPe05e4JkGhwY=; b=r/wHbo9SK44uBx75OVWbuXdPSzxpU/9HKISqj4CipVBbR1DMQi2TwPbSG6yZ6zQ6OA D6w7eWiH18RTH5NxvokL4zfFX9IUydqak9ZK/rVJkSYA/PMyIvrT6QCNZPouu9loX9YO TfMhMgle+P/ENhPJQ6GL2mfjM2R230/uIm48aT8QAiZPohJtMIjv8zRXjD7zxreq9JpF m5hOamG6EzsHvLlhcFTKqtWBowHUPQmb2OnFnGQh0NP8eWCc/4rMCYa5zbExLVchHXZs U+BB5LRz5y3t8aoipKDrLzRKICQsKEbkv4OwzQSeh9kRkLLqDEjkVWwS0/c/PnKLFv9P fXnQ== X-Received: by 10.194.173.163 with SMTP id bl3mr68167395wjc.10.1386226453061; Wed, 04 Dec 2013 22:54:13 -0800 (PST) Original-Received: by 10.216.47.129 with HTTP; Wed, 4 Dec 2013 22:54:13 -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:81421 Archived-At: --089e013c62205025aa04ecc3ffd0 Content-Type: text/plain; charset=ISO-8859-1 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 > --089e013c62205025aa04ecc3ffd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I managed to compile your mac port and inserted:
=
=A0 =A0 =A0 newlim =3D (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:

> =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.chiba-u.ac.jp

--089e013c62205025aa04ecc3ffd0--