From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: undo-auto--undoable-change infloop Date: Tue, 26 Jul 2022 15:04:02 +0300 Message-ID: <831qu8dqrx.fsf@gnu.org> References: <87o7xc1qbh.fsf@web.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15543"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 26 14:06:27 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oGJKV-0003sW-Dq for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Jul 2022 14:06:27 +0200 Original-Received: from localhost ([::1]:43126 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oGJKU-0002Ls-En for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Jul 2022 08:06:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57562) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGJI6-0001IF-UQ for emacs-devel@gnu.org; Tue, 26 Jul 2022 08:03:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37104) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGJI6-0004Sx-LN; Tue, 26 Jul 2022 08:03:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=7vgKGQrTeQId5r7iI2Sk/un3H5pIVdJD0CD4h57M0Hk=; b=rQbcgpR5QdyM 0Y/QFSijw4+uL3BFpwivF6PrhUlNobnfyY7rLXQss5UufGTCRLSGO/P8vurRVb7uvNa3wrbJ/LvDO C8RDf0AOj6Lo+IW7u6toZ0yhFWFG9fXAFfh864B0wSvneoisER+i6zoN5D1EGltzenJ5eJLsjc90H 2RbUvc+JAI67dDdHsCU3ToWnHdKOeu5w7M9cn5aHboKYo6947ByBfMZQqaD9gUJ3uYbOvbaqCajAJ lP48LYtKy/oWsiRY7J5nuc8irnrxNg/xJqc6FCrrTUQyABkZRPKqVBUlchFLGKS5MpHNA3KziSQIt OWt1zUC3zZbHpCNwn1jChw==; Original-Received: from [87.69.77.57] (port=4054 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGJI6-0005Md-52; Tue, 26 Jul 2022 08:03:58 -0400 In-Reply-To: <87o7xc1qbh.fsf@web.de> (message from Michael Heerdegen on Tue, 26 Jul 2022 05:54:42 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292676 Archived-At: > From: Michael Heerdegen > Date: Tue, 26 Jul 2022 05:54:42 +0200 > > does somebody have a guess what is happening here? After automatically > replacing thousands of matches in a buffer with my el-search, I got a > sluggish Emacs afterwards, after a short pause. Emacs consumed 100% of > one CPU. It took me hours to find something, and it seems to be > unrelated to my own code: `undo-auto--undoable-change'. It seems to > recurse very deep, or to be called extremely often. I managed to > produce a backtrace, see below. How is that recursion even possible - > what could be going on? I don't know what happened, but undo-auto--boundary-timer is invoked 10 sec after the timer is set. Perhaps this kind of problem can happen when there are many undoable changes, and processing them takes more than 10 sec?