From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Geoff Shannon Newsgroups: gmane.emacs.bugs Subject: bug#17713: First portion of `bt full` Date: Fri, 6 Jun 2014 01:51:42 -0700 Message-ID: References: <83mwdq4gvk.fsf@gnu.org> <83iooe4gdm.fsf@gnu.org> <83egz24fec.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0112cbfc39a58004fb26fa6d X-Trace: ger.gmane.org 1402044806 9097 80.91.229.3 (6 Jun 2014 08:53:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Jun 2014 08:53:26 +0000 (UTC) Cc: 17713@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 06 10:53:19 2014 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 1Wsptl-0006cn-Cl for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Jun 2014 10:53:17 +0200 Original-Received: from localhost ([::1]:45905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wsptk-0006Mh-VR for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Jun 2014 04:53:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wsptc-0006Lc-07 for bug-gnu-emacs@gnu.org; Fri, 06 Jun 2014 04:53:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsptX-0006aa-2p for bug-gnu-emacs@gnu.org; Fri, 06 Jun 2014 04:53:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsptW-0006aT-Vh for bug-gnu-emacs@gnu.org; Fri, 06 Jun 2014 04:53:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WsptW-00082n-Ax for bug-gnu-emacs@gnu.org; Fri, 06 Jun 2014 04:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Geoff Shannon Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Jun 2014 08:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17713 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17713-submit@debbugs.gnu.org id=B17713.140204474130840 (code B ref 17713); Fri, 06 Jun 2014 08:53:02 +0000 Original-Received: (at 17713) by debbugs.gnu.org; 6 Jun 2014 08:52:21 +0000 Original-Received: from localhost ([127.0.0.1]:46528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wspsq-00081M-Vy for submit@debbugs.gnu.org; Fri, 06 Jun 2014 04:52:21 -0400 Original-Received: from mail-wg0-f47.google.com ([74.125.82.47]:64395) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wspso-000812-3l for 17713@debbugs.gnu.org; Fri, 06 Jun 2014 04:52:19 -0400 Original-Received: by mail-wg0-f47.google.com with SMTP id k14so1500115wgh.6 for <17713@debbugs.gnu.org>; Fri, 06 Jun 2014 01:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=2PmlSKIB1+AjgxzJZZdUPMG/OpV+qKAm0VZKFWqCuVQ=; b=GmQCikK5YEEB7ZB9m2l3d/WsxCecyTDCtdC3IPGqKD9BNMnK3V7FE3CEYasubMofzi oPMINVJ1GjR+xxmB1DrTibalPCeRZNNS+QaecmQNx2wstNL0jpXTTssjhgBH36/QIzQ7 GwXVD2cxrxbT12T1I0pu7VaVitiCXIZl7JO0QLuYNm7wZrNGwDqLBhPcd5IVfXa4F09p 9t6z+PncU9t8rVHEEv7MHo0W4Pn606lMeP9SZ4dejl/FR9bT4kw5uE5T1ArdddjM2PoQ F8mS+oKrDVdBkskI5Vb5mjeiDqcfwaku4lKUMn/y7L7Qo2bk008awBULAmY8/hsqnnVS 94gg== X-Received: by 10.194.157.68 with SMTP id wk4mr4786136wjb.42.1402044732251; Fri, 06 Jun 2014 01:52:12 -0700 (PDT) Original-Received: by 10.194.61.84 with HTTP; Fri, 6 Jun 2014 01:51:42 -0700 (PDT) In-Reply-To: <83egz24fec.fsf@gnu.org> X-Google-Sender-Auth: AGzdC6MAa_3NyWYW-iuzvNCSr6s 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:90120 Archived-At: --089e0112cbfc39a58004fb26fa6d Content-Type: text/plain; charset=UTF-8 On Fri, Jun 6, 2014 at 1:21 AM, Eli Zaretskii wrote: > > From: Geoff Shannon > > Date: Fri, 6 Jun 2014 01:06:43 -0700 > > Cc: 17713@debbugs.gnu.org > > > > > Did you customize any GC-related options, like gc-cons-threshold? > > > > I didn't personally, but I use emacs Prelude which does this: > > > > (setq gc-cons-threshold 50000000) > > That's 50MB! The default is 400000 (400K). > > > I'm guessing that's likely the cause of this? > > Could well be. It means Emacs invokes GC after it has created at > least 50MB worth of Lisp objects. Wading through all of them and > finding those which can be discarded will indeed take a while. > > I suggest you remove that customization. The default is well tuned, > and you will hardly ever notice GC going on. > I'm very on board with using the default, especially if this is a possible result. Also, some more evidence which seems to my gc-cons-threshold as the problem: It appears that the 'hung' emacs is still responsive, _occasionally_. As in, during a random test for responsive-ness (i.e. mashing on the keyboard) I got the cursor to move one space forwards. Then no more. My theory is that the GC is running (which takes a while because it was allowed to get so big). Then because it's not getting much smaller (am I correct in thinking that emacs does conservative GC?), it almost immediately goes back to trying to GC, which again takes a while. Basically, since the number of lisp objects is so large, the GC takes up way too much time since it takes so long to run. So the trade-off for putting that limit so high is no garbage collection for a LONG time, and then after that garbage collection takes all the available time... Not good. So, if this theory is correct, then the reproduction of this bug should be to use emacs for a while with the gc-cons-threshold turned up high. And eventually this should happen again. Seems like this can probably be closed as 'User error'. -- Geoff Nothing is ever easy. --089e0112cbfc39a58004fb26fa6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 6, 2014 at 1:21 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Geoff Shannon <geoffpshannon@gmail.com>=
> Date: Fri, 6 Jun 2014 01:06:43 -0700
> Cc: 17713@d= ebbugs.gnu.org
>
> > Did you customize any GC-related options, like gc-cons-threshold?=
>
> I didn't personally, but I use emacs Prelude which does this:
>
> (setq gc-cons-threshold 50000000)

That's 50MB! =C2=A0The default is 400000 (400K).

> I'm guessing that's likely the cause of this?

Could well be. =C2=A0It means Emacs invokes GC after it has created a= t
least 50MB worth of Lisp objects. =C2=A0Wading through all of them and
finding those which can be discarded will indeed take a while.

I suggest you remove that customization. =C2=A0The default is well tuned, and you will hardly ever notice GC going on.

I'm very on boa= rd with using the default, especially if this is a possible result.

=
Also, some more evidence which seems to my= gc-cons-threshold as the problem:
It appears that the 'hung' emacs i= s still responsive, _occasionally_.=C2=A0 As in, during a
random test for responsive-ness (i.e. mashing on the key= board) I got the cursor to
move one space forwards.=C2=A0 Then no mor= e.

My theory is that the GC is running (which takes a while because = it was allowed to get
so big).=C2=A0 Then because it's not getting = much smaller (am I correct in thinking that emacs
does conservative GC?), it almost immediately goes back to trying to GC, wh= ich
again takes a while.

Basically, since= the number of lisp objects is so large, the GC takes up way too much
time since it takes so long to run. So the= trade-off for putting that limit so high is
no garbage collection for a LONG time, and then after that garbage co= llection takes
all the available time...=C2=A0 Not good.

So, if this theory is correct, then the reproduction of this bug sho= uld be to use emacs for
a while with th= e gc-cons-threshold turned up high.=C2=A0 And eventually this should happen= again.

Seems= like this can probably be closed as 'User error'.

--
Geoff

Nothing is ever = easy.
--089e0112cbfc39a58004fb26fa6d--