From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Marshall\, Simon" <Simon.Marshall@misys.com>
Cc: emacs-pretest-bug@gnu.org, Chong Yidong <cyd@stupidchicken.com>
Subject: Re: [22.1.90]: Point before start of properties
Date: Wed, 20 Feb 2008 12:17:01 -0500 [thread overview]
Message-ID: <jwvodablfwz.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <6EE216E1AA959543A555C60FF34FB7670305BF82@maileube01.misys.global.ad> (Simon Marshall's message of "Wed, 20 Feb 2008 11:31:30 -0000")
>> 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
next prev parent reply other threads:[~2008-02-20 17:17 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-08 16:35 [22.1.90]: Point before start of properties Marshall, Simon
2008-02-10 3:26 ` Stefan Monnier
2008-02-10 15:22 ` Chong Yidong
2008-02-12 17:52 ` Marshall, Simon
2008-02-12 18:32 ` Stefan Monnier
2008-02-13 10:13 ` Marshall, Simon
2008-02-18 19:52 ` Stefan Monnier
2008-02-19 10:37 ` Marshall, Simon
2008-02-19 16:00 ` Stefan Monnier
2008-02-19 17:23 ` Marshall, Simon
2008-02-19 17:31 ` David Kastrup
2008-02-20 9:44 ` Marshall, Simon
2008-02-19 21:59 ` Stefan Monnier
2008-02-20 11:31 ` Marshall, Simon
2008-02-20 17:17 ` Stefan Monnier [this message]
2008-02-20 19:40 ` Eli Zaretskii
2008-02-21 9:16 ` Richard Stallman
2008-02-21 16:02 ` Stefan Monnier
2008-02-22 3:16 ` Stephen J. Turnbull
2008-02-22 15:18 ` [OT] Deugging optimized code (was: [22.1.90]: Point before start of properties) Stefan Monnier
2008-02-22 15:41 ` Andreas Schwab
2008-02-22 22:20 ` Stephen J. Turnbull
2008-02-22 16:31 ` [22.1.90]: Point before start of properties Eli Zaretskii
2008-02-22 16:27 ` Eli Zaretskii
2008-02-22 22:09 ` Miles Bader
2008-02-23 19:29 ` Richard Stallman
2008-02-23 21:18 ` Eli Zaretskii
2008-02-24 15:22 ` Richard Stallman
2008-02-24 19:59 ` Eli Zaretskii
2008-02-25 10:57 ` Richard Stallman
2008-02-25 15:55 ` Stefan Monnier
2008-02-24 20:36 ` Tom Tromey
2008-02-25 10:57 ` Richard Stallman
2008-02-21 22:27 ` Richard Stallman
[not found] ` <6EE216E1AA959543A555C60FF34FB76702B2DB02@maileube01.misys.global.ad>
2008-02-19 14:45 ` Marshall, Simon
2008-02-19 23:09 ` Richard Stallman
2008-02-10 18:42 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvodablfwz.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=Simon.Marshall@misys.com \
--cc=cyd@stupidchicken.com \
--cc=emacs-pretest-bug@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).