From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Lexbind (was: Emacs 23.3 released) Date: Thu, 17 Mar 2011 06:28:04 -0400 Message-ID: References: <87sjuulr20.fsf@gmail.com> <87aah2p1s1.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1300357713 790 80.91.229.12 (17 Mar 2011 10:28:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 17 Mar 2011 10:28:33 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 17 11:28:28 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q0ARQ-00085p-22 for ged-emacs-devel@m.gmane.org; Thu, 17 Mar 2011 11:28:28 +0100 Original-Received: from localhost ([127.0.0.1]:38321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0ARP-0005j9-Ii for ged-emacs-devel@m.gmane.org; Thu, 17 Mar 2011 06:28:27 -0400 Original-Received: from [140.186.70.92] (port=48011 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0ARJ-0005is-S0 for emacs-devel@gnu.org; Thu, 17 Mar 2011 06:28:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0AR2-00073y-R2 for emacs-devel@gnu.org; Thu, 17 Mar 2011 06:28:21 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:46464) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0AR2-00073u-PX for emacs-devel@gnu.org; Thu, 17 Mar 2011 06:28:04 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Q0AR2-0000HR-F6; Thu, 17 Mar 2011 06:28:04 -0400 In-reply-to: (message from Juanma Barranquero on Thu, 17 Mar 2011 02:59:38 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137334 Archived-At: > From: Juanma Barranquero > Date: Thu, 17 Mar 2011 02:59:38 +0100 > Cc: emacs-devel@gnu.org > > I've had several hangups while reading from the minibuffer. No CPU > usage, but no response whatsoever so I had to kill Emacs. > > I just had one while running under GDB, so I Ctrl-C and I got the > attached backtrace. > [...] > (gdb) bt > #0 0x0112c987 in next_element_from_buffer (it=0x88c250) at xdisp.c:6744 Is this with today's sources from the lexbind-new branch? Because line 6744 in xdisp.c is the closing brace of next_element_from_buffer with today's bzr repo. How can Emacs get stuck in such a line? However, since this seems to be an optimized build, the backtrace is not guaranteed to make sense. I suggest to recompile without optimizations and post a backtrace if and when that hangs. > #1 0x0112171f in get_next_display_element (it=0x88c250) at xdisp.c:5630 > #2 0x0112292b in move_it_in_display_line_to (it= out>, to_charpos=-1, to_x=-1, op=0) at xdisp.c:6956 > #3 0x0112620f in move_it_to (it=0x88c250, to_charpos=-1, to_x=-1, > to_y=-1, to_vpos=1, op=4) at xdisp.c:7333 > #4 0x0112e87f in move_it_by_lines (it=0x88c250, dvpos=1, need_y_p=1) > at xdisp.c:7757 > #5 0x01136a6e in try_scrolling (window=, > just_this_one_p=0, arg_scroll_conservatively=143165576, scroll_step=0, > temp_scroll_step=0, last_line_misfit=0) at xdisp.c:13128 > #6 0x0114e0cd in redisplay_window (window=, > just_this_one_p=0) at xdisp.c:14168 > #7 0x011502b3 in redisplay_window_0 (window=56712709) at xdisp.c:12362 > #8 0x01012961 in internal_condition_case_1 (bfun=0x1150290 > , arg=56712709, handlers=53689030, > hfun=0x1109770 ) at eval.c:1536 > #9 0x0110f137 in redisplay_windows (window=) at > xdisp.c:12342 This all looks like a normal redisplay cycle to me, and I don't see how it could possibly hang, especially without using CPU. If you can reproduce this in a non-optimized build, try stepping after interrupting Emacs, and see where it loops or in what function call it gets stuck. Also, perhaps try bt in the other threads, maybe they are stuck, not the Lisp thread.