Re: [22.1.90]: Point before start of properties

[Stefan Monnier]

>> 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