From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "David PONCE" Newsgroups: gmane.emacs.devel Subject: Re: NT Emacs crashes when selecting a menubar item Date: Tue, 30 Jul 2002 13:28:32 +0200 (MET DST) Sender: emacs-devel-admin@gnu.org Message-ID: <4726.43486359647$1028024941@news.gmane.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1028024941 3953 127.0.0.1 (30 Jul 2002 10:29:01 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 30 Jul 2002 10:29:01 +0000 (UTC) Cc: Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17ZUFQ-00011e-00 for ; Tue, 30 Jul 2002 12:29:00 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17ZUX5-0001Ns-00 for ; Tue, 30 Jul 2002 12:47:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17ZUFh-0004Et-00; Tue, 30 Jul 2002 06:29:17 -0400 Original-Received: from smtp-out-2.wanadoo.fr ([193.252.19.254] helo=mel-rto2.wanadoo.fr) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17ZUF2-0004DW-00; Tue, 30 Jul 2002 06:28:36 -0400 Original-Received: from mel-rta9.wanadoo.fr (193.252.19.69) by mel-rto2.wanadoo.fr (6.5.007) id 3D1838B60122092F; Tue, 30 Jul 2002 12:28:32 +0200 Original-Received: from mail-web10 (193.252.19.77) by mel-rta9.wanadoo.fr (6.5.007) id 3D2A791A00A0862A; Tue, 30 Jul 2002 12:28:32 +0200 Original-Received: from '' by www.wanadoo.fr with HTTP; Original-To: Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: X-Spam-Report: 7.4 hits, 5 required; * 4.0 -- 'Message-Id' was added by a relay * 1.8 -- Message-Id is not valid, according to RFC-2822 * 1.6 -- 'Message-Id' was added by a relay (2) Xref: main.gmane.org gmane.emacs.devel:6173154 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6173 Richard, I can confirm that GC is the cause of the problem. I printed messages before, after, and in the middle of the loop that build the widget_value tree and when entering GC. Here is a snippet of printed result that clearly shows that GC happened while running single_submenu: [...] w32menu.set_frame_menubar before init_menu_items consing/threshold(375580= /134217727) w32menu.set_frame_menubar before single_submenu consing/threshold(375580/= 134217727) w32menu.set_frame_menubar after single_submenu consing/threshold(376568/1= 34217727) w32menu.set_frame_menubar before single_submenu consing/threshold(376568/= 134217727) w32menu.set_frame_menubar after single_submenu consing/threshold(466128/1= 34217727) w32menu.set_frame_menubar before single_submenu consing/threshold(466128/= 134217727) w32menu.set_frame_menubar after single_submenu consing/threshold(485808/1= 34217727) w32menu.set_frame_menubar before single_submenu consing/threshold(485808/= 134217727) w32menu.set_frame_menubar after single_submenu consing/threshold(485920/1= 34217727) w32menu.set_frame_menubar before single_submenu consing/threshold(485920/= 134217727) w32menu.set_frame_menubar after single_submenu consing/threshold(486276/1= 34217727) w32menu.set_frame_menubar before single_submenu consing/threshold(486276/= 134217727) w32menu.set_frame_menubar after single_submenu consing/threshold(501404/1= 34217727) w32menu.set_frame_menubar before single_submenu consing/threshold(501404/= 134217727) *** GC entered consing/threshold(509952/10000000) *** GC entered consing/threshold(872/10000000) w32menu.set_frame_menubar after single_submenu consing/threshold(6444/134= 217727) w32menu.set_frame_menubar before single_submenu consing/threshold(6444/13= 4217727) w32menu.set_frame_menubar after single_submenu consing/threshold(7120/134= 217727) w32menu.set_frame_menubar before single_submenu consing/threshold(7120/13= 4217727) w32menu.set_frame_menubar after single_submenu consing/threshold(10568/13= 4217727) w32menu.set_frame_menubar before single_submenu consing/threshold(10568/1= 34217727) w32menu.set_frame_menubar after single_submenu consing/threshold(24800/13= 4217727) w32menu.set_frame_menubar before single_submenu consing/threshold(24800/1= 34217727) w32menu.set_frame_menubar after single_submenu consing/threshold(39056/13= 4217727) w32menu.set_frame_menubar before single_submenu consing/threshold(39056/1= 34217727) w32menu.set_frame_menubar after single_submenu consing/threshold(100504/1= 34217727) w32menu.set_frame_menubar after finish_menu_items consing/threshold(10050= 4/134217727) *** GC entered consing/threshold(101352/10000000) [...] In fact 10000000 is the `gc-cons-threshold' value that the Semantic parser locally uses to speed up things. The parser is called from `menu-bar-update-hook' to produce the parse tree used to build the imenu index. And can be called too via an idle timer to re-parse the buffer when necessary. Also the parser explicitly calls `garbage-collect' to free memory before it locally binds `gc-cons-threshold'. Maybe the parser hook or timer are asynchronously activated while building the widget_value tree=3F IMO it is definitively a bug in Emacs to consider that the range of code that builds the menu tree is GC safe, because user's Lisp code can call `garbage-collect' or re-bind `gc-cons-threshold' to a value lower than the maximum one set by `inhibit_garbage_collection' to inhibit GC. As Lisp strings data can be relocated even if the Lisp_Object is protected, it is only safe to store string data locations when it is really sure that GC can't happen. My proposed patch to w32menu.c make widget_value insensible to GC because it only contains pointers to safe strings, copied in local heap. The counterpart is a little overhead. From what I observed, I didn't noticed a significant slow down when using menus. Maybe another possible solution could be that `inhibit_garbage_collection' uses a flag to block GC=3F By default it would be t to allow GC and could be set to nil to really disable GC. Something like this: (let ((inhibit_garbage_collection nil)) (garbage_collect) ;; Does nothing! ) I don't know if a such flag should be exported to Lisp. Perhaps its use would be dangerous! David