From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: gerd.moellmann@t-online.de (Gerd Moellmann) Newsgroups: gmane.emacs.bugs Subject: Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row Date: 29 Mar 2002 21:25:15 +0100 Sender: bug-gnu-emacs-admin@gnu.org Message-ID: <86vgbfjf4k.fsf@gerd.dnsq.org> References: <200203280044.g2S0i7g00924@shade.twinsun.com> <7458-Thu28Mar2002103446+0200-eliz@is.elta.co.il> <200203281843.g2SIhI601544@shade.twinsun.com> <86wuvvekuf.fsf@gerd.dnsq.org> <200203291941.g2TJfNd29395@shade.twinsun.com> Reply-To: gerd@gnu.org NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1017434362 1523 127.0.0.1 (29 Mar 2002 20:39:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 29 Mar 2002 20:39:22 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16r39d-0000OS-00 for ; Fri, 29 Mar 2002 21:39:22 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16r39Z-0001KO-00; Fri, 29 Mar 2002 15:39:17 -0500 Original-Received: from mailout02.sul.t-online.com ([194.25.134.17]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16r38j-0001FW-00 for ; Fri, 29 Mar 2002 15:38:25 -0500 Original-Received: from fwd11.sul.t-online.de by mailout02.sul.t-online.com with smtp id 16r2w6-0000MN-06; Fri, 29 Mar 2002 21:25:22 +0100 Original-Received: from gerd.dnsq.org (520015515780-0001@[217.85.171.130]) by fwd11.sul.t-online.com with esmtp id 16r2w1-0I1no8C; Fri, 29 Mar 2002 21:25:17 +0100 Original-Received: (from gerd@localhost) by gerd.dnsq.org (8.11.6/8.11.6) id g2TKPFo01086; Fri, 29 Mar 2002 21:25:15 +0100 (CET) (envelope-from gerd@gnu.org) X-Authentication-Warning: gerd.dnsq.org: gerd set sender to gerd@gnu.org using -f Original-To: Paul Eggert In-Reply-To: <200203291941.g2TJfNd29395@shade.twinsun.com> Original-Lines: 49 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 X-Sender: 520015515780-0001@t-dialin.net Errors-To: bug-gnu-emacs-admin@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.bugs:295 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:295 Paul Eggert writes: > Thanks. Unfortunately I know little about this area. To illustrate > my naivete, can I ask a couple of questions? Why can dispnew.c's > direct_output_for_insert get away with modifying BEG_UNCHANGED but not > END_UNCHANGED? It's likely that I simply took that from old redisplay, which did the same, assuming it suffices and without checking thorougly. Looking at it again, I think it would be cleaner if direct_output_for_insert called mark_window_display_accurate to do the job. I'll make that change on Sunday, when I'm at home. > Is it possible that direct_output_for_insert was called during the > scenario that I describe ("C-x C-s" immediately followed by "a")? It's hard to tell, but it could be. Seeing that there are no intervals in the buffer makes it more likely. Do you know if the buffer had a non-nil after-change-function? > Also, I can run 'gdb' and print things if you like. For example: > > #3 0x00064aa8 in find_first_unchanged_at_end_row (w=0xb97, delta=0xffbedd24, > delta_bytes=0xffbedd20) at xdisp.c:11169 > (gdb) p current_buffer->text[0] > $8 = { > beg = 0x1eb9478 "[some long and boring text that is not relevant to the bug, I hope...........................................................................................................................................]"..., > gpt = 4139, z = 8159, gpt_byte = 4139, z_byte = 8159, gap_size = 1073, > modiff = 6648, save_modiff = 6647, overlay_modiff = 5544, > beg_unchanged = 4137, end_unchanged = 3936, unchanged_modified = 6647, > overlay_unchanged_modified = 5544, intervals = 0x0, markers = 541792076} What I can see from that is -- there was one modification since the last completed redisplay, because the modified tick in unchanged_modified is one less than modiff. -- unchanged info says there are 4137 chars unchanged at the buffer start, and 3936 unchanged at the end, sum 8073, and point-max (z) is 8159. This certainly doesn't fit the addition of 1 char to the buffer (if that was all that happened in the buffer). Could you please try to print, in the frame for try_window_id, for example, (gdb) p *it->w->current_matrix I don't know if the matrix is still there in a core dump, so that may fail.