From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: [22.1.90]: Point before start of properties Date: Wed, 20 Feb 2008 12:17:01 -0500 Message-ID: References: <6EE216E1AA959543A555C60FF34FB76702E48034@maileube01.misys.global.ad> <87wspcj0ou.fsf@stupidchicken.com> <6EE216E1AA959543A555C60FF34FB76702EED4A1@maileube01.misys.global.ad> <6EE216E1AA959543A555C60FF34FB76702EEDA6E@maileube01.misys.global.ad> <6EE216E1AA959543A555C60FF34FB7670300E86B@maileube01.misys.global.ad> <6EE216E1AA959543A555C60FF34FB7670305B82C@maileube01.misys.global.ad> <6EE216E1AA959543A555C60FF34FB7670305BF82@maileube01.misys.global.ad> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1203527857 665 80.91.229.12 (20 Feb 2008 17:17:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Feb 2008 17:17:37 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, Chong Yidong To: "Marshall\, Simon" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 20 18:18:01 2008 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.50) id 1JRsZi-0007uP-Ps for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2008 18:17:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRsZD-0007Il-RD for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2008 12:17:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRsZ9-0007I4-NK for emacs-devel@gnu.org; Wed, 20 Feb 2008 12:17:07 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRsZ9-0007Hr-9O for emacs-devel@gnu.org; Wed, 20 Feb 2008 12:17:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRsZ9-0007Hn-0q for emacs-devel@gnu.org; Wed, 20 Feb 2008 12:17:07 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRsZ8-0002FG-UF for emacs-devel@gnu.org; Wed, 20 Feb 2008 12:17:07 -0500 Original-Received: from mx10.gnu.org ([199.232.76.166]) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1JRsZ8-0007Ag-GC for emacs-pretest-bug@gnu.org; Wed, 20 Feb 2008 12:17:06 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1JRsZ5-0002EW-Le for emacs-pretest-bug@gnu.org; Wed, 20 Feb 2008 12:17:06 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRsZ5-0002EF-AI for emacs-pretest-bug@gnu.org; Wed, 20 Feb 2008 12:17:03 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAO3vu0fO+J2cdGdsb2JhbACQUgEwn3uBAQ X-IronPort-AV: E=Sophos;i="4.25,382,1199682000"; d="scan'208";a="14755522" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 20 Feb 2008 12:17:02 -0500 Original-Received: from pastel.home ([206.248.157.156]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id ATL35502; Wed, 20 Feb 2008 12:17:02 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 03C3B7F48; Wed, 20 Feb 2008 12:17:02 -0500 (EST) In-Reply-To: <6EE216E1AA959543A555C60FF34FB7670305BF82@maileube01.misys.global.ad> (Simon Marshall's message of "Wed, 20 Feb 2008 11:31:30 -0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:89711 gmane.emacs.pretest.bugs:21250 Archived-At: >> As explained (sorry for not noticing this earlier), i1 is >> stack-allocated and not fully initialized, which is why it looks >> like garbage. That's completely normal, we're wasting our time here. >> Better go back to your actual "point before start of properties" > error. >> I've removed the INT_LISPLIKE check. > Luckily, just moving > update_interval into a new file intervals2.c was enough. Building all > with CFLAGS="-g -O1 -fno-unit-at-a-time -fno-crossjumping > -Wno-pointer-sign" allows me to reproduce the error call. Building just > intervals2.c with -O0 rather than -O1 will not reproduce the error call. > With optimisation, when I stop, I see: > (gdb) b intervals2.c:34 > Breakpoint 3 at 0x197c6c: file intervals2.c, line 34. > (gdb) r -Q > Starting program: > /homedev/marshals/ftp/emacs-22.2-pretests/gcc-4.2.3-g-O1/src/emacs -Q > warning: Temporarily disabling breakpoints for unloaded shared library > "/usr/lib/ld.so.1" > Breakpoint 4 at 0xc7580: file xterm.c, line 7866. > C-x C-f intervals.c RET > Breakpoint 3, update_interval (i=0x95eaf4, pos=1771) at intervals2.c:34 > 34 error ("Point before start of properties"); > (gdb) p *i > $1 = { > total_length = 36, > position = 1782, > left = 0x95eb10, > right = 0x95e950, > up = { > interval = 0x95e934, > obj = 9824564 > }, > up_obj = 0, > gcmarkbit = 0, > write_protect = 0, > visible = 0, > front_sticky = 0, > rear_sticky = 0, > plist = 9842845 > } > Note that the condition that allows the call of error in: > else if (NULL_PARENT (i)) > error ("Point before start of properties"); > Expands to: > else if (((i)->up_obj || (i)->up.interval == 0)) > error ("Point before start of properties"); > Yet the condition should be false: > (gdb) p (((i)->up_obj || (i)->up.interval == 0)) > $2 = 0 > I guess it's perfectly possible that this is not due to miscompiled code > (as I reported on gcc's bugzilla), since I guess what gdb is reporting > may not be accurate either. Does this sound reasonable? Any thoughts? Whenever I have to debug optimized code, I tend to rely a lot on good'ol fprintf (stderr, ...), so try to add a few such printfs just before calling `error', where you print things like `i', i->up.interval, i->up_obj, ... This may also help you get a better sense about the trustworthiness of GDB's output. Intervals have had bugs in the past due to asynchronous code (i.e. intervals being changed from signal handlers). It might still be a possibility (tho it sounds unlikely since your problem is reliably reproducible), so you may also want to add fprintfs at other places in the code, such as the entrance/exit of balance_possible_root_interval (and the entrance/exit of the update_intervals function, of course). > The backtrace might be illuminating - at least insomuch you might have > an idea what I could look at. Nope, sorry. > Is there something I can use to dump the entire interval tree? No, there's no such thing either. Stefan