[22.1.90]: Point before start of properties

[22.1.90]: Point before start of properties

[Marshall, Simon]

During pretesting before 22.1 I reported a problem whereby occasionally
I would see the minibuffer message "Error in menu-bar-update-hook:
(error Point before start of properties)" and the hook would be left
with a value of nil.  (See "Error in menu-bar-update-hook: (error Point
before start of properties)" from July 2006.)  At the time I had a go at
tracking it down but without any success, and it continues to bite me
every so often to this day.  So, occasionally, I have to do M-x msb-mode
twice to turn msb-mode off and then back on again.  

I was hoping the pretest version might magically have a fix for it, but
unfortunately not.  I figured I would have another go at debugging it
and found that it seems suspiciously easy to reproduce.  All I have to
do is this:

(gdb) b intervals.c:794
Breakpoint 1 at 0x195d90: file intervals.c, line 794.
(gdb) r -Q

Then in emacs do C-x C-f ~/.../src/intervals.c RET and bang:

Breakpoint 1, update_interval (i=0x8b1af4, pos=1771) at intervals.c:794
794                 error ("Point before start of properties");
(gdb) 

If I don't set the breakpoint before I run emacs, but visit the file and
only then in gdb put the breakpoint on and continue, I can trigger this
error just by scrolling the window with the scrollbar.

It seems too easy to trigger this error, so I am not sure I am really
seeing the same problem that occasionally results in
menu-bar-update-hook being set to nil.  Is the triggering of this error
normal in certain circumstances?  If not, is the above enough for
someone to take a look at it?  Otherwise, is there anything I can do to
track down the problem for menu-bar-update-hook?

Simon.

In GNU Emacs 22.1.90.1 (sparc-sun-solaris2.8, Motif Version 2.1.0)
 of 2008-01-31 on risksun2
Windowing system distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--x-includes=/usr/openwin/include:/usr/dt/include:/usr/local/include:/u
sr/local/X11/include'
'--x-libraries=/usr/openwin/lib:/usr/dt/lib:/usr/local/lib:/usr/local/X1
1/lib' '--with-x-toolkit=motif''


Misys and Misys International Banking Systems is a trading name for Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. PLEASE REFER TO THE EXECUTED CONTRACT BETWEEN YOU AND THE RELEVANT MEMBER OF THE MISYS GROUP FOR THE IDENTITY OF THE CONTRACTING PARTY WITH WHICH YOU ARE DEALING.

Re: [22.1.90]: Point before start of properties

[Stefan Monnier]

> (gdb) b intervals.c:794
> Breakpoint 1 at 0x195d90: file intervals.c, line 794.
> (gdb) r -Q

> Then in emacs do C-x C-f ~/.../src/intervals.c RET and bang:

> Breakpoint 1, update_interval (i=0x8b1af4, pos=1771) at intervals.c:794
> 794                 error ("Point before start of properties");
> (gdb) 

Sorry, can't reproduce it here,


        Stefan

Re: [22.1.90]: Point before start of properties

[Chong Yidong]

"Marshall, Simon" <Simon.Marshall@misys.com> writes:

> (gdb) b intervals.c:794
> Breakpoint 1 at 0x195d90: file intervals.c, line 794.
> (gdb) r -Q
>
> Then in emacs do C-x C-f ~/.../src/intervals.c RET and bang:
>
> Breakpoint 1, update_interval (i=0x8b1af4, pos=1771) at intervals.c:794
> 794                 error ("Point before start of properties");
> (gdb) 

I can't reproduce this.  It might be a Sparc-only issue; does it
happen to you on other platforms?

RE: [22.1.90]: Point before start of properties

[Marshall, Simon]

> > (gdb) b intervals.c:794
> > Breakpoint 1 at 0x195d90: file intervals.c, line 794.
> > (gdb) r -Q
> >
> > Then in emacs do C-x C-f ~/.../src/intervals.c RET and bang:
> >
> > Breakpoint 1, update_interval (i=0x8b1af4, pos=1771) at
intervals.c:794
> > 794                 error ("Point before start of properties");
> > (gdb) 
> 
> I can't reproduce this.  It might be a Sparc-only issue; does it
> happen to you on other platforms?

Hmm.  You're right, I can't reproduce it on RHEL-5 with its gcc-4.1.2,
even when I disable as much as I can to make it like a configuration
that I know fails on solaris (--with-x-toolkit=lucid --without-xaw3d
--without-xpm --without-jpeg --without-tiff --without-gif --without-png
--without-toolkit-scroll-bars)

On solaris:
I can reproduce it (ie, it breaks on the call to error as above) with
lucid and motif scrollbars (tried with gcc-4.1.2)
I can reproduce it with gcc-4.1.2 (-g and -g -O2) and gcc-4.2.3 (-g -O
and -g -O2).
I cannot reproduce it with gcc-4.2.3 (-g) and CC-5.7 (-g).

It suggests that it might be a gcc optimisation bug, but any idea as to
why it should be solaris-specific?  Any ideas as to how to investigate
this?

I tried #undefing GNU_MALLOC and/or HAVE_ALLOCA, but I can still
reproduce it.

Simon.


 "Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. 
 
We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

Re: [22.1.90]: Point before start of properties

[Stefan Monnier]

> I can reproduce it (ie, it breaks on the call to error as above) with
> lucid and motif scrollbars (tried with gcc-4.1.2)
> I can reproduce it with gcc-4.1.2 (-g and -g -O2) and gcc-4.2.3 (-g -O
> and -g -O2).
> I cannot reproduce it with gcc-4.2.3 (-g) and CC-5.7 (-g).

So, adding -O (or -O2) to gcc-4.2.3 triggers the problem, and switching
to gcc-4.1.2 triggers it as well?

It does sound like it may be a compiler bug, but [putting on my
compiler writer hat] it's still at least as likely that the bug is in
our code and just isn't triggered in more common circumstances
(e.g. a missing `volatile' or something like that, maybe?).

First thing: try to reproduce the problem with -DENABLE_CHECKING.
This may help us catch the problem at some earlier poin in the execution
(it's a long shot, but you never know).

Then try to narrow down the problematic source file: compile all files
with "gcc-4.2.3 -g" except for one (e.g. intervals.c) and see if you con
still reproduce the problem.  If you can, recompile intervals.c with
"gcc-4.2.3 -g" to double check that the problem then disappears.
If that's not that file, then use binary search to figure out which file
is causing trouble.


        Stefan

RE: [22.1.90]: Point before start of properties

[Marshall, Simon]

> So, adding -O (or -O2) to gcc-4.2.3 triggers the problem, and 
> switching to gcc-4.1.2 triggers it as well?

Yes.  Btw, I didn't mention before that gcc gives me lots of warnings of
the form "dispnew.c:3061: warning: incompatible implicit declaration of
built-in function 'alloca'".  (That is the reason why I tried undefing
GNU_MALLOC and HAVE_ALLOCA, though IIRC I could not get rid of the
warnings and made no difference to the problem of calling error at
intervals.c:794.)  Could this be relevant?

> First thing: try to reproduce the problem with -DENABLE_CHECKING.
> This may help us catch the problem at some earlier poin in 
> the execution (it's a long shot, but you never know).

With make CFLAGS="-g -O -DENABLE_CHECKING=1
-DSYSTEM_PURESIZE_EXTRA=1300000", I do not get any earlier abort if I do
"C-x C-f intervals.c RET", ie, it reaches the call to error at
intervals.c:794 as before.  However, I do get an earlier abort if I do
"C-x C-f int TAB" to complete the file name intervals.c:

% ~/slash/usr/local/bin/gdb ./emacs
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from
terminal]
DISPLAY = dtp020071.misys-risk.com:0.0
TERM = xterm
Breakpoint 1 at 0x116a20: file emacs.c, line 432.
Breakpoint 2 at 0x13b930: file sysdep.c, line 1384.
(gdb) b intervals.c:794
Breakpoint 3 at 0x1edc48: file intervals.c, line 794.
(gdb) r -Q
Starting program:
/homedev/marshals/ftp/emacs-22.2-pretests/gcc-4.2.3-g-O/src/emacs -Q
warning: Temporarily disabling breakpoints for unloaded shared library
"/usr/lib/ld.so.1"
Breakpoint 4 at 0xeea10: file xterm.c, line 7866.

In the emacs frame I did "C-x C-f int TAB" and got:

Breakpoint 1, abort () at emacs.c:432
432       kill (getpid (), SIGABRT);
(gdb) where
#0  abort () at emacs.c:432
#1  0x0017ec8c in die (msg=0x256d88 "non-interval", 
    file=0x256d98 "intervals.c", line=162) at alloc.c:6338
#2  0x001ebc30 in intervals_equal (i0=<value optimized out>,
i1=0xffbecebc)
    at intervals.c:162
#3  0x001eea08 in offset_intervals (buffer=<value optimized out>,
start=12, 
    length=54) at intervals.c:1049
#4  0x0014c560 in insert_from_string_1 (string=<value optimized out>,
pos=0, 
    pos_byte=0, nchars=54, nbytes=54, inherit=0, before_markers=0)
    at insdel.c:1172
#5  0x0014c7ac in insert_from_string (string=8626576, pos=0, pos_byte=0,

    length=54, length_byte=54, inherit=0) at insdel.c:1068
#6  0x0019449c in general_insert_function (insert_func=0x14cc1c
<insert>, 
    insert_from_string_func=0x14c730 <insert_from_string>, inherit=0,
nargs=1, 
    args=<value optimized out>) at editfns.c:2178
#7  0x00194578 in Finsert (nargs=1, args=0xffbed124) at editfns.c:2222
#8  0x001534c8 in do_completion () at minibuf.c:2029
#9  0x001538d0 in Fminibuffer_complete () at minibuf.c:2152
#10 0x0019efac in Ffuncall (nargs=1, args=<value optimized out>) at
eval.c:2990
#11 0x0019b988 in Fcall_interactively (function=5493857,
record_flag=5318657, 
    keys=5382148) at callint.c:861
#12 0x0011bfb0 in Fcommand_execute (cmd=5493857, record_flag=5318657, 
    keys=5318657, special=<value optimized out>) at keyboard.c:10053
#13 0x001312a0 in command_loop_1 () at keyboard.c:1876
#14 0x0019d3e8 in internal_condition_case (bfun=0x12f430
<command_loop_1>, 
    handlers=5386913, hfun=0x12632c <cmd_error>) at eval.c:1484
#15 0x00125534 in command_loop_2 () at keyboard.c:1330
#16 0x0019d4c4 in internal_catch (tag=5413513, func=0x125508
<command_loop_2>, 
    arg=5318657) at eval.c:1224
#17 0x0012611c in command_loop () at keyboard.c:1297
#18 0x001264d4 in recursive_edit_1 () at keyboard.c:1007
#19 0x00154810 in read_minibuf (map=5303197, initial=8448995,
prompt=2727747, 
    backup_n=<value optimized out>, expflag=0, histvar=5467833,
histpos=0, 
    defalt=8448995, allow_props=0, inherit_input_method=0) at
minibuf.c:751
#20 0x0015508c in Fcompleting_read (prompt=2727747, 
    collection=<value optimized out>, predicate=<value optimized out>, 
    require_match=5318657, initial_input=<value optimized out>,
hist=5467833, 
    def=8448995, inherit_input_method=5318657) at minibuf.c:1807
#21 0x00158d68 in Fread_file_name (prompt=2727747, dir=8448995, 
    default_filename=8448995, mustmatch=5318657, 
    initial=<value optimized out>, predicate=5467401) at fileio.c:6414
#22 0x0019f1b0 in Ffuncall (nargs=-4269544, args=<value optimized out>)
    at eval.c:3012
#23 0x001d3e5c in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=7) at bytecode.c:679
#24 0x0019eabc in funcall_lambda (fun=2727260, nargs=2,
arg_vector=0xffbedbc8)
    at eval.c:3180
#25 0x0019eba0 in apply_lambda (fun=2727260, args=5318657, eval_flag=1)
    at eval.c:3104
#26 0x0019e468 in Feval (form=<value optimized out>) at eval.c:2366
#27 0x0019a568 in Fcall_interactively (function=5663633,
record_flag=5318657, 
    keys=5382148) at callint.c:379
#28 0x0011bfb0 in Fcommand_execute (cmd=5663633, record_flag=5318657, 
    keys=5318657, special=<value optimized out>) at keyboard.c:10053
#29 0x001312a0 in command_loop_1 () at keyboard.c:1876
#30 0x0019d3e8 in internal_condition_case (bfun=0x12f430
<command_loop_1>, 
    handlers=5386913, hfun=0x12632c <cmd_error>) at eval.c:1484
#31 0x00125534 in command_loop_2 () at keyboard.c:1330
#32 0x0019d4c4 in internal_catch (tag=5377025, func=0x125508
<command_loop_2>, 
    arg=5318657) at eval.c:1224
#33 0x001260d8 in command_loop () at keyboard.c:1309
#34 0x001264d4 in recursive_edit_1 () at keyboard.c:1007
#35 0x00126790 in Frecursive_edit () at keyboard.c:1068
#36 0x00118224 in main (argc=2, argv=0xffbee404) at emacs.c:1770

Lisp Backtrace:
"minibuffer-complete" (0x503c00)
"call-interactively" (0x53d461)
"read-file-name" (0x299f43)
"find-file-read-args" (0x299f43)
"call-interactively" (0x566b91)
(gdb) up
#1  0x0017ec8c in die (msg=0x256d88 "non-interval", 
    file=0x256d98 "intervals.c", line=162) at alloc.c:6338
6338      abort ();
(gdb) up
#2  0x001ebc30 in intervals_equal (i0=<value optimized out>,
i1=0xffbecebc)
    at intervals.c:162
162       if (DEFAULT_INTERVAL_P (i0) || DEFAULT_INTERVAL_P (i1))
(gdb) print i0
$3 = <value optimized out>
(gdb) print i1
$4 = (INTERVAL) 0xffbecebc
(gdb) print *i1
$5 = {
  total_length = 2055860, 
  position = 5244928, 
  left = 0x8, 
  right = 0x84afb3, 
  up = {
    interval = 0x80ebe3, 
    obj = 8448995
  }, 
  up_obj = 0, 
  gcmarkbit = 0, 
  write_protect = 0, 
  visible = 0, 
  front_sticky = 0, 
  rear_sticky = 0, 
  plist = 5318657
}
(gdb) up
#3  0x001eea08 in offset_intervals (buffer=<value optimized out>,
start=12, 
    length=54) at intervals.c:1049
1049              else if (! intervals_equal (prev, &newi))
(gdb) print prev
No symbol "prev" in current context.
(gdb) print newi
No symbol "newi" in current context.
(gdb) 

I can understand not being able to see i0 in intervals_equal, but I
don't understand not being able to see prev and newi in the caller.  I
tried to reproduce this with CFLAGS="-g -DENABLE_CHECKING=1
-DSYSTEM_PURESIZE_EXTRA=1300000", ie, no optimisation, but could not
reproduce the abort (or call of error).

> Then try to narrow down the problematic source file: compile all files
> with "gcc-4.2.3 -g" except for one (e.g. intervals.c) and see 
> if you con still reproduce the problem.  If you can, recompile
intervals.c with
> "gcc-4.2.3 -g" to double check that the problem then disappears.
> If that's not that file, then use binary search to figure out 
> which file is causing trouble.

Blimey.  Compiling intervals.c with CFLAGS="-g -O -DENABLE_CHECKING=1
-DSYSTEM_PURESIZE_EXTRA=1300000" (everything else the same except for no
-O) results in an emacs that triggers the abort as soon as I type C-x
C-f:

Emacs fatal error: intervals.c:162: non-interval

Breakpoint 1, abort () at emacs.c:432
432       kill (getpid (), SIGABRT);
(gdb) where
#0  abort () at emacs.c:432
#1  0x00313618 in die (msg=0x4a3d80 "non-interval", 
    file=0x4a3d90 "intervals.c", line=162) at alloc.c:6338
#2  0x003f52f4 in intervals_equal (i0=<value optimized out>,
i1=0xffbecf2c)
    at intervals.c:162
#3  0x003f8040 in offset_intervals (buffer=<value optimized out>,
start=12, 
    length=42) at intervals.c:1049
#4  0x00290e3c in insert_from_string_1 (string=10872851, pos=0,
pos_byte=0, 
    nchars=42, nbytes=42, inherit=0, before_markers=0) at insdel.c:1172
#5  0x0029060c in insert_from_string (string=10872851, pos=0,
pos_byte=0, 
    length=42, length_byte=42, inherit=0) at insdel.c:1068
#6  0x0033371c in general_insert_function (insert_func=0x28fadc
<insert>, 
    insert_from_string_func=0x290558 <insert_from_string>, inherit=0,
nargs=1, 
    args=0xffbed2e8) at editfns.c:2178
#7  0x003337c4 in Finsert (nargs=1, args=0x40020000) at editfns.c:2222
#8  0x0029d40c in read_minibuf (map=7719821, initial=10872851,
prompt=5143059, 
    backup_n=0, expflag=0, histvar=7881401, histpos=0, defalt=10872851, 
    allow_props=0, inherit_input_method=0) at minibuf.c:730
#9  0x002a2c38 in Fcompleting_read (prompt=5143059, collection=7884305, 
    predicate=10872851, require_match=7735297, initial_input=10872851, 
    hist=7881401, def=10872851, inherit_input_method=7735297) at
minibuf.c:1807
#10 0x002bf2a0 in Fread_file_name (prompt=5143059, dir=10872851, 
    default_filename=10872851, mustmatch=7735297, initial=7735297, 
    predicate=7735297) at fileio.c:6414
#11 0x0034ee70 in Ffuncall (nargs=5, args=0xffbed5d0) at eval.c:3012
#12 0x003c4fa4 in Fbyte_code (bytestr=5142611, vector=5142692,
maxdepth=40)
    at bytecode.c:679
#13 0x0034fec0 in funcall_lambda (fun=5142572, nargs=2,
arg_vector=0xffbed8d0)
    at eval.c:3180
#14 0x0034f59c in apply_lambda (fun=5142572, args=5143053, eval_flag=1)
    at eval.c:3104
#15 0x0034bf60 in Feval (form=5143045) at eval.c:2366
#16 0x00340a2c in Fcall_interactively (function=8060817,
record_flag=7735297, 
    keys=7798788) at callint.c:379
#17 0x00251c34 in Fcommand_execute (cmd=8060817, record_flag=7735297, 
    keys=7735297, special=7735297) at keyboard.c:10053
#18 0x0022a448 in command_loop_1 () at keyboard.c:1876
#19 0x003481d0 in internal_condition_case (bfun=0x225be4
<command_loop_1>, 
    handlers=7803553, hfun=0x224bac <cmd_error>) at eval.c:1484
#20 0x002254b4 in command_loop_2 () at keyboard.c:1330
#21 0x00347808 in internal_catch (tag=7793665, func=0x225488
<command_loop_2>, 
    arg=7735297) at eval.c:1224
#22 0x00225428 in command_loop () at keyboard.c:1309
#23 0x00224108 in recursive_edit_1 () at keyboard.c:1007
#24 0x00224790 in Frecursive_edit () at keyboard.c:1068
#25 0x002213e0 in main (argc=2, argv=0xffbee444) at emacs.c:1770

Lisp Backtrace:
"read-file-name" (0x4e7a13)
"find-file-read-args" (0x4e7a13)
"call-interactively" (0x7aff91)
(gdb) 

Do you think these ENABLE_CHECKING aborts are genuine?  Could there be a
problem with the definition of NULL_INTERVAL_P (I see its definition has
changed)?

Compiling everything with CFLAGS="-g -O" results in error being called
at intervals.c:794 on C-x C-f intervals.c RET, as described before.
Recompiling intervals.c with CFLAGS="-g" results in error not being
called.

Compiling everything with CFLAGS="-g" results in error not being called.
Recompiling intervals.c with CFLAGS="-g -0" results in error being
called.

So, ENABLE_CHECKING not withstanding, it appears to be a problem with
the optimisation of intervals.c itself.

Any other thoughts?

Thanks, Simon.


 "Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. 
 
We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

Re: [22.1.90]: Point before start of properties

[Stefan Monnier]

>> So, adding -O (or -O2) to gcc-4.2.3 triggers the problem, and 
>> switching to gcc-4.1.2 triggers it as well?

> Yes.  Btw, I didn't mention before that gcc gives me lots of warnings of
> the form "dispnew.c:3061: warning: incompatible implicit declaration of
> built-in function 'alloca'".  (That is the reason why I tried undefing
> GNU_MALLOC and HAVE_ALLOCA, though IIRC I could not get rid of the
> warnings and made no difference to the problem of calling error at
> intervals.c:794.)  Could this be relevant?

Any warning outside of intervals.c seem unlikely to be a good source of
the problem.  Do you ever get any kind of warning when compiling
intervals.c?

Also you said that the problem could be triggered with gcc-4.1.2 even
without optimization, is that really true?  If so, can you try again
with gcc-4.1.2 and no optimizations, to get better debug info?

Another thing: do you know if your compilation uses USE_LSB_TAG or not?
Is it a 64bit or 32bit memory model?
Have you tried to compile it with -DUSE_LISP_UNION_TYPE just to see if
it hides the problem (or give some compilation warning at least)?

> I can understand not being able to see i0 in intervals_equal, but I
> don't understand not being able to see prev and newi in the caller.  I
> tried to reproduce this with CFLAGS="-g -DENABLE_CHECKING=1
> -DSYSTEM_PURESIZE_EXTRA=1300000", ie, no optimisation, but could not
> reproduce the abort (or call of error).

The fact that you don't get the assertion failure when compiling without
optimizations indicates that this assertion failure is unlikely to
be a fluke, tho the "CHECK (!INT_LISPLIKE (i)" thingy is fishy.

The fields of the i1 interval don't seem to be valid (0x8 can't be
a left pointer, the right point seems to be misaligned (maybe it's
actually a string and the up_obj bit should be set), total_length and
position could only make sense in a buffer of at least 5-6MB).
Then again, we have no idea if we're really looking at i1 and
its contents.

> Do you think these ENABLE_CHECKING aborts are genuine?

Maybe.

> Could there be a problem with the definition of NULL_INTERVAL_P (I see
> its definition has changed)?

The INT_LISPLIKE thingy is fishy.  I suspect that it may misfire (the
"struct interval" may have size 28, so intervals pointers may not all be
aligned on multiples of 8, which implies that an interval pointer may
have the same tag bits as a buffer).

> So, ENABLE_CHECKING not withstanding, it appears to be a problem with
> the optimisation of intervals.c itself.
> Any other thoughts?

Not really.  If you can reproduce it without optimizations, then you may
be able to track it down more precisely and figure out if it's
a compiler bug or an Emacs bug.


        Stefan

RE: [22.1.90]: Point before start of properties

[Marshall, Simon]

> > Yes.  Btw, I didn't mention before that gcc gives me lots of
warnings of
> > the form "dispnew.c:3061: warning: incompatible implicit declaration
of
> > built-in function 'alloca'".  (That is the reason why I tried
undefing
> > GNU_MALLOC and HAVE_ALLOCA, though IIRC I could not get rid of the
> > warnings and made no difference to the problem of calling error at
> > intervals.c:794.)  Could this be relevant?
> 
> Any warning outside of intervals.c seem unlikely to be a good source
of
> the problem.  Do you ever get any kind of warning when compiling
> intervals.c?

No.

> Also you said that the problem could be triggered with gcc-4.1.2 even
> without optimization, is that really true?  If so, can you try again
> with gcc-4.1.2 and no optimizations, to get better debug info?

Ah, I did say that didn't I.  A typo I think.  (I cannot reproduce it
without optimisation, though I have since installed 4.2.3 over the top
of 4.1.2.  I tried to reproduce it today with
CC=sparc-sun-solaris2.8-gcc-4.1.2, and I could with CFLAGS="-g -O" and
"-g -O2", but not with CFLAGS="-g".  Apologies for that.)

> Another thing: do you know if your compilation uses USE_LSB_TAG or
not?
> Is it a 64bit or 32bit memory model?
> Have you tried to compile it with -DUSE_LISP_UNION_TYPE just to see if
> it hides the problem (or give some compilation warning at least)?

I'm guessing it's 32bit.  With CFLAGS="-g -O2 -DUSE_LISP_UNION_TYPE",
there were no suspicious compiler warnings (non at all for intervals.c)
and it still hit the intervals.c:794 breakpoint.

> > I can understand not being able to see i0 in intervals_equal, but I
> > don't understand not being able to see prev and newi in the caller.
I
> > tried to reproduce this with CFLAGS="-g -DENABLE_CHECKING=1
> > -DSYSTEM_PURESIZE_EXTRA=1300000", ie, no optimisation, but could not
> > reproduce the abort (or call of error).
> 
> The fact that you don't get the assertion failure when compiling
without
> optimizations indicates that this assertion failure is unlikely to
> be a fluke, tho the "CHECK (!INT_LISPLIKE (i)" thingy is fishy.
> 
> The fields of the i1 interval don't seem to be valid (0x8 can't be
> a left pointer, the right point seems to be misaligned (maybe it's
> actually a string and the up_obj bit should be set), total_length and
> position could only make sense in a buffer of at least 5-6MB).
> Then again, we have no idea if we're really looking at i1 and
> its contents.
> 
> > Do you think these ENABLE_CHECKING aborts are genuine?
> 
> Maybe.
> 
> > Could there be a problem with the definition of NULL_INTERVAL_P (I
see
> > its definition has changed)?
> 
> The INT_LISPLIKE thingy is fishy.  I suspect that it may misfire (the
> "struct interval" may have size 28, so intervals pointers may not all
be
> aligned on multiples of 8, which implies that an interval pointer may
> have the same tag bits as a buffer).
> 
> > So, ENABLE_CHECKING not withstanding, it appears to be a problem
with
> > the optimisation of intervals.c itself.
> > Any other thoughts?
> 
> Not really.  If you can reproduce it without optimizations, 
> then you may
> be able to track it down more precisely and figure out if it's
> a compiler bug or an Emacs bug.

Thanks for the suggestions and the careful reading of my report.  Is
there anything else you think I could try, eg, to deal with the size of
struct interval?  I can confirm that it is 28, though it is 28 with or
without optimisation.  I tried padding it to 32 by adding a dummy int to
it, but it still hit the breakpoint with optimisation.

I don't like the thought of trying to break up intervals.c, to binary
search for a particular problem function, so any other suggestions are
welcome.

Simon.



 "Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. 
 
We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

Re: [22.1.90]: Point before start of properties

[Stefan Monnier]

> Ah, I did say that didn't I.  A typo I think.  (I cannot reproduce it
> without optimisation, though I have since installed 4.2.3 over the top
> of 4.1.2.  I tried to reproduce it today with
> CC=sparc-sun-solaris2.8-gcc-4.1.2, and I could with CFLAGS="-g -O" and
> "-g -O2", but not with CFLAGS="-g".  Apologies for that.)

Too bad.

> Thanks for the suggestions and the careful reading of my report.  Is
> there anything else you think I could try, eg, to deal with the size of
> struct interval?  I can confirm that it is 28, though it is 28 with or
> without optimisation.  I tried padding it to 32 by adding a dummy int to
> it, but it still hit the breakpoint with optimisation.

Yes, as I said, the assertion failure is probably not a fluke, altough
the check itself is a bit fishy.

> I don't like the thought of trying to break up intervals.c, to binary
> search for a particular problem function, so any other suggestions are
> welcome.

No idea, sorry,


        Stefan

RE: [22.1.90]: Point before start of properties

[Marshall, Simon]

> > Thanks for the suggestions and the careful reading of my report.  Is
> > there anything else you think I could try, eg, to deal with the size
of
> > struct interval?  I can confirm that it is 28, though it is 28 with
or
> > without optimisation.  I tried padding it to 32 by adding a dummy
int to
> > it, but it still hit the breakpoint with optimisation.
> 
> Yes, as I said, the assertion failure is probably not a fluke, altough
> the check itself is a bit fishy.

OK, together with another suggestion, I rebuilt emacs with CFLAGS="-g
-O1 -fno-unit-at-a-time -DENABLE_CHECKING".  This time I am able to get
better debug info than before.

Breakpoint 2 at 0x13d8e0: file sysdep.c, line 1384.
(gdb) r -Q   
Starting program:
/homedev/marshals/ftp/emacs-22.2-pretests/gcc-4.2.3-g-O2/src/emacs -Q
warning: Temporarily disabling breakpoints for unloaded shared library
"/usr/lib/ld.so.1"
Breakpoint 3 at 0xf26ac: file xterm.c, line 7866.

C-x C-f i	; first letter of "intervals.c" is necessary to provoke
abort

Emacs fatal error: intervals.c:159: non-interval

Breakpoint 1, abort () at emacs.c:432
432       kill (getpid (), SIGABRT);
(gdb) up 2
#2  0x001eca58 in intervals_equal (i0=0x956588, i1=0xffbed22c) at
intervals.c:162
162       if (DEFAULT_INTERVAL_P (i0) || DEFAULT_INTERVAL_P (i1))
(gdb) p *i0
$1 = {
  total_length = 57, 
  position = 12, 
  left = 0x95656c, 
  right = 0x0, 
  up = {
    interval = 0x79d404, 
    obj = 7984132
  }, 
  up_obj = 1, 
  gcmarkbit = 0, 
  write_protect = 0, 
  visible = 0, 
  front_sticky = 0, 
  rear_sticky = 0, 
  plist = 4028417
}
(gdb) p *i1
$2 = {
  total_length = 1171396, 
  position = 4028417, 
  left = 0x0, 
  right = 0x1, 
  up = {
    interval = 0x1, 
    obj = 1
  }, 
  up_obj = 1, 
  gcmarkbit = 1, 
  write_protect = 1, 
  visible = 1, 
  front_sticky = 1, 
  rear_sticky = 1, 
  plist = 4028417
}

It seems that i0 does point to a valid interval, but i1 does not look
good.  Has it been GCed?  Is there anything that will output a
buffer's/string's property tree?  Sorry to ask again, but if this is a
good place to go digging, what should I go digging for?

(gdb) where
#0  abort () at emacs.c:432
#1  0x001879ec in die (msg=0x259328 "non-interval", file=0x2592e0
"intervals.c", 
    line=159) at alloc.c:6338
#2  0x001eca58 in intervals_equal (i0=0x956588, i1=0xffbed22c) at
intervals.c:162
#3  0x001ee6e8 in adjust_intervals_for_insertion (tree=0x956588,
position=57, length=1)
    at intervals.c:1049
#4  0x001efa0c in offset_intervals (buffer=0x79d400, start=57, length=1)
    at intervals.c:1472
#5  0x0014c494 in insert_1_both (string=0xffbed414 "i=x\001", nchars=1,
nbytes=1, 
    inherit=1, prepare=1, before_markers=0) at insdel.c:1037
#6  0x0014c064 in insert_and_inherit (string=0xffbed414 "i=x\001",
nbytes=1)
    at insdel.c:771
#7  0x001660c4 in internal_self_insert (c=105, noautofill=0) at
cmds.c:516
#8  0x0011d0b8 in command_loop_1 () at keyboard.c:1840
#9  0x0019fcfc in internal_condition_case (bfun=0x11b30c
<command_loop_1>, 
    handlers=4096673, hfun=0x11ab24 <cmd_error>) at eval.c:1484
#10 0x0011af50 in command_loop_2 () at keyboard.c:1330
#11 0x0019f7a8 in internal_catch (tag=4120201, func=0x11af24
<command_loop_2>, 
    arg=4028417) at eval.c:1224
#12 0x0011af10 in command_loop () at keyboard.c:1297
#13 0x0011a614 in recursive_edit_1 () at keyboard.c:1007
#14 0x0015269c in read_minibuf (map=4012941, initial=7575955,
prompt=2738499, 
    backup_n=<value optimized out>, expflag=0, histvar=4170425,
histpos=0, 
    defalt=7575955, allow_props=0, inherit_input_method=0) at
minibuf.c:751
#15 0x00154a4c in Fcompleting_read (prompt=2738499, collection=<value
optimized out>, 
    predicate=<value optimized out>, require_match=4028417, 
    initial_input=<value optimized out>, hist=4170425, def=7575955, 
    inherit_input_method=4028417) at minibuf.c:1807
#16 0x00161d34 in Fread_file_name (prompt=2738499, dir=7575955, 
    default_filename=7575955, mustmatch=4028417, initial=<value
optimized out>, 
    predicate=4169993) at fileio.c:6414
#17 0x001a2618 in Ffuncall (nargs=-4269488, args=<value optimized out>)
at eval.c:3012
#18 0x001d6460 in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=7) at bytecode.c:679
#19 0x001a2c70 in funcall_lambda (fun=2738012, nargs=2,
arg_vector=0xffbedc00)
    at eval.c:3180
#20 0x001a2908 in apply_lambda (fun=2738012, args=4028417, eval_flag=1)
at eval.c:3104
#21 0x001a1704 in Feval (form=<value optimized out>) at eval.c:2366
#22 0x0019c7c0 in Fcall_interactively (function=4349841,
record_flag=4028417, 
    keys=4091908) at callint.c:379
#23 0x0012ff58 in Fcommand_execute (cmd=4349841, record_flag=4028417,
keys=4028417, 
    special=<value optimized out>) at keyboard.c:10053
#24 0x0011d17c in command_loop_1 () at keyboard.c:1876
#25 0x0019fcfc in internal_condition_case (bfun=0x11b30c
<command_loop_1>, 
    handlers=4096673, hfun=0x11ab24 <cmd_error>) at eval.c:1484
#26 0x0011af50 in command_loop_2 () at keyboard.c:1330
#27 0x0019f7a8 in internal_catch (tag=4086785, func=0x11af24
<command_loop_2>, 
    arg=4028417) at eval.c:1224
#28 0x0011aecc in command_loop () at keyboard.c:1309
#29 0x0011a614 in recursive_edit_1 () at keyboard.c:1007
#30 0x0011a908 in Frecursive_edit () at keyboard.c:1068
#31 0x00119040 in main (argc=2, argv=0xffbee43c) at emacs.c:1770

Lisp Backtrace:
"read-file-name" (0x29c943)
"find-file-read-args" (0x29c943)
"call-interactively" (0x425f91)
(gdb) 



 "Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. 
 
We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

Re: [22.1.90]: Point before start of properties

[David Kastrup]

"Marshall, Simon" <Simon.Marshall@misys.com> writes:

>> > Thanks for the suggestions and the careful reading of my report.  Is
>> > there anything else you think I could try, eg, to deal with the size
> of
>> > struct interval?  I can confirm that it is 28, though it is 28 with
> or
>> > without optimisation.  I tried padding it to 32 by adding a dummy
> int to
>> > it, but it still hit the breakpoint with optimisation.
>> 
>> Yes, as I said, the assertion failure is probably not a fluke, altough
>> the check itself is a bit fishy.
>
> OK, together with another suggestion, I rebuilt emacs with CFLAGS="-g
> -O1 -fno-unit-at-a-time -DENABLE_CHECKING".  This time I am able to get
> better debug info than before.

DEBUG tells you


** When you are trying to analyze failed assertions, it will be
essential to compile Emacs either completely without optimizations or
at least (when using GCC) with the -fno-crossjumping option.  Failure
to do so may make the compiler recycle the same abort call for all
assertions in a given function, rendering the stack backtrace useless
for identifying the specific failed assertion.


-- 
David Kastrup

RE: [22.1.90]: Point before start of properties

[Marshall, Simon]

> > OK, together with another suggestion, I rebuilt emacs with
CFLAGS="-g
> > -O1 -fno-unit-at-a-time -DENABLE_CHECKING".  This time I am able to
get
> > better debug info than before.
> 
> ** When you are trying to analyze failed assertions, it will be
> essential to compile Emacs either completely without optimizations or
> at least (when using GCC) with the -fno-crossjumping option.  Failure
> to do so may make the compiler recycle the same abort call for all
> assertions in a given function, rendering the stack backtrace useless
> for identifying the specific failed assertion.

Unfortunately I cannot reproduce the original problem without
optimisation, but I'll use -fno-crossjumping in future.


 "Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. 
 
We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

Re: [22.1.90]: Point before start of properties

[Stefan Monnier]

>> > Thanks for the suggestions and the careful reading of my report.  Is
>> > there anything else you think I could try, eg, to deal with the size of
>> > struct interval?  I can confirm that it is 28, though it is 28 with or
>> > without optimisation.  I tried padding it to 32 by adding a dummy int to
>> > it, but it still hit the breakpoint with optimisation.
>> 
>> Yes, as I said, the assertion failure is probably not a fluke, altough
>> the check itself is a bit fishy.

Actually, now I think it may very well be a fluke: the `i1' that looks
so odd is actually stack allocated (so it may indeed be on a mult-of-4
even if you pad it to 32bytes) and is not fully initialized (because
intervals_equal only looks at the `plist' field) so it may very well
look like a buffer.

> It seems that i0 does point to a valid interval, but i1 does not look
> good.  Has it been GCed?

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.


        Stefan

RE: [22.1.90]: Point before start of properties

[Marshall, Simon]

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

Ok, thanks for the explanation.  Going back to without
-DENABLE_CHECKING, I've split up intervals.c.  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?

It seems i's "up" interval is valid:

(gdb) p *i->up.interval
$3 = {
  total_length = 94, 
  position = 1817, 
  left = 0x95eaf4, 
  right = 0x95e988, 
  up = {
    interval = 0x95e9dc, 
    obj = 9824732
  }, 
  up_obj = 0, 
  gcmarkbit = 0, 
  write_protect = 0, 
  visible = 0, 
  front_sticky = 0, 
  rear_sticky = 0, 
  plist = 9845373
}

The backtrace might be illuminating - at least insomuch you might have
an idea what I could look at.  Is there something I can use to dump the
entire interval tree?  Perhaps I could use that to see when a bogus
interval arises.  Or perhaps the fact that it appears to happen from
fontification-functions might help.  Or scare.

(gdb) where
#0  update_interval (i=0x95daf4, pos=1771) at intervals2.c:34
#1  0x00172668 in update_syntax_table (charpos=1771, count=-1, init=0, 
    object=<value optimized out>) at syntax.c:180
#2  0x00139a98 in re_match_2_internal (bufp=0x465fb0, string1=0x0,
size1=0, 
    string2=0x96e7b0 "/* Code for doing intervals.\n   Copyright (C)
1993, 1994, 1995, 1997, 1998, 2001, 2002, 2003, 2004,\n", ' ' <repeats
17 times>, "2005, 2006, 2007, 2008  Free Software Foundation,
Inc.\n\nThis file is part of GNU Em"..., size2=1806, pos=1770, 
    regs=0x45aeb0, stop=1806) at regex.c:6087
#3  0x001350c4 in re_search_2 (bufp=0x465fb0, 
    str1=0x96e7b0 "/* Code for doing intervals.\n   Copyright (C) 1993,
1994, 1995, 1997, 1998, 2001, 2002, 2003, 2004,\n", ' ' <repeats 17
times>, "2005, 2006, 2007, 2008  Free Software Foundation, Inc.\n\nThis
file is part of GNU Em"..., size1=1806, 
    str2=0x9811f0 "", size2=0, startpos=1770, range=-1770,
regs=0x45aeb0, stop=1806)
    at regex.c:4434
#4  0x0012aa00 in search_buffer (string=<value optimized out>, pos=1807,
pos_byte=1807, 
    lim=1, lim_byte=1, n=-1, RE=1, trt=4675585, inverse_trt=4675585,
posix=0)
    at search.c:1144
#5  0x0012a42c in search_command (string=2502667, bound=4675585,
noerror=4779993, 
    count=<value optimized out>, direction=<value optimized out>, RE=1,
posix=0)
    at search.c:978
#6  0x0012cd44 in Fre_search_backward (regexp=2502667, bound=4675585,
noerror=4779993, 
    count=8) at search.c:2231
#7  0x00156b10 in Ffuncall (nargs=5, args=<value optimized out>) at
eval.c:3003
#8  0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=86) at bytecode.c:679
#9  0x00157094 in funcall_lambda (fun=2502404, nargs=1,
arg_vector=0xffbeaa14)
    at eval.c:3180
#10 0x00156bf4 in Ffuncall (nargs=2, args=<value optimized out>) at
eval.c:3039
#11 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=23) at bytecode.c:679
#12 0x00157094 in funcall_lambda (fun=2502228, nargs=0,
arg_vector=0xffbeabc4)
    at eval.c:3180
#13 0x00156bf4 in Ffuncall (nargs=1, args=<value optimized out>) at
eval.c:3039
#14 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=51) at bytecode.c:679
#15 0x00157094 in funcall_lambda (fun=8848228, nargs=1,
arg_vector=0xffbead74)
    at eval.c:3180
#16 0x00156bf4 in Ffuncall (nargs=2, args=<value optimized out>) at
eval.c:3039
#17 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=204) at bytecode.c:679
#18 0x00157094 in funcall_lambda (fun=7471364, nargs=0,
arg_vector=0xffbeaf34)
    at eval.c:3180
#19 0x00156bf4 in Ffuncall (nargs=1, args=<value optimized out>) at
eval.c:3039
#20 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=16) at bytecode.c:679
#21 0x00157094 in funcall_lambda (fun=8824484, nargs=0,
arg_vector=0xffbeb0e4)
    at eval.c:3180
#22 0x00156bf4 in Ffuncall (nargs=1, args=<value optimized out>) at
eval.c:3039
#23 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=214) at bytecode.c:679
#24 0x00157094 in funcall_lambda (fun=8835844, nargs=3,
arg_vector=0xffbeb2bc)
    at eval.c:3180
#25 0x00156bf4 in Ffuncall (nargs=4, args=<value optimized out>) at
eval.c:3039
#26 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=62) at bytecode.c:679
#27 0x00157094 in funcall_lambda (fun=7119588, nargs=2,
arg_vector=0xffbeb47c)
    at eval.c:3180
#28 0x00156bf4 in Ffuncall (nargs=3, args=<value optimized out>) at
eval.c:3039
#29 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
---Type <return> to continue, or q <return> to quit---
    vector=<value optimized out>, maxdepth=0) at bytecode.c:679
#30 0x00157094 in funcall_lambda (fun=7088452, nargs=4,
arg_vector=0xffbeb64c)
    at eval.c:3180
#31 0x00156bf4 in Ffuncall (nargs=5, args=<value optimized out>) at
eval.c:3039
#32 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=56) at bytecode.c:679
#33 0x00157094 in funcall_lambda (fun=7120292, nargs=1,
arg_vector=0xffbeb824)
    at eval.c:3180
#34 0x00156bf4 in Ffuncall (nargs=2, args=<value optimized out>) at
eval.c:3039
#35 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=96) at bytecode.c:679
#36 0x00157094 in funcall_lambda (fun=2425052, nargs=3,
arg_vector=0xffbeb9f4)
    at eval.c:3180
#37 0x00156bf4 in Ffuncall (nargs=4, args=<value optimized out>) at
eval.c:3039
#38 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=137) at bytecode.c:679
#39 0x00157094 in funcall_lambda (fun=2421692, nargs=3,
arg_vector=0xffbebbb4)
    at eval.c:3180
#40 0x00156bf4 in Ffuncall (nargs=4, args=<value optimized out>) at
eval.c:3039
#41 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=32) at bytecode.c:679
#42 0x00157094 in funcall_lambda (fun=2420508, nargs=2,
arg_vector=0xffbebee0)
    at eval.c:3180
#43 0x00156bf4 in Ffuncall (nargs=3, args=<value optimized out>) at
eval.c:3039
#44 0x00156504 in run_hook_with_args (nargs=3, args=0xffbebedc,
cond=to_completion)
    at eval.c:2652
#45 0x0015635c in Frun_hook_with_args (nargs=3, args=0xffbebedc) at
eval.c:2540
#46 0x00156a00 in Ffuncall (nargs=4, args=<value optimized out>) at
eval.c:2974
#47 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=32) at bytecode.c:679
#48 0x00155e58 in Feval (form=<value optimized out>) at eval.c:2330
#49 0x001549b0 in internal_lisp_condition_case (var=5069401,
bodyform=2435885, 
    handlers=2435957) at eval.c:1429
#50 0x00182dcc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=135) at bytecode.c:869
#51 0x00157094 in funcall_lambda (fun=2435508, nargs=2,
arg_vector=0xffbec2ec)
    at eval.c:3180
#52 0x00156bf4 in Ffuncall (nargs=3, args=<value optimized out>) at
eval.c:3039
#53 0x001824bc in Fbyte_code (bytestr=<value optimized out>, 
    vector=<value optimized out>, maxdepth=20) at bytecode.c:679
#54 0x00157094 in funcall_lambda (fun=2435204, nargs=1,
arg_vector=0xffbec60c)
    at eval.c:3180
#55 0x00156bf4 in Ffuncall (nargs=2, args=<value optimized out>) at
eval.c:3039
#56 0x00154d4c in internal_condition_case_2 (bfun=0x15679c <Ffuncall>,
nargs=2, 
    args=0xffbec608, handlers=4675633, hfun=0x5b110 <safe_eval_handler>)
at eval.c:1583
#57 0x0005b220 in safe_call (nargs=2, args=0xffbec608) at xdisp.c:2341
#58 0x0005b24c in safe_call1 (fn=7476585, arg=12728) at xdisp.c:2361
#59 0x0005c7d4 in handle_fontified_prop (it=<value optimized out>) at
xdisp.c:3296
#60 0x0005c1b4 in handle_stop (it=0xffbec8d8) at xdisp.c:3047
#61 0x00061120 in next_element_from_buffer (it=0xffbec8d8) at
xdisp.c:6320
#62 0x00060214 in get_next_display_element (it=0xffbec8d8) at
xdisp.c:5578
#63 0x00071a9c in display_line (it=0xffbec8d8) at xdisp.c:16066
#64 0x0006d6b8 in try_window (window=<value optimized out>, pos=
      {charpos = 7969796, bytepos = 7969792}, check_margins=1) at
xdisp.c:13645
#65 0x0006c898 in redisplay_window (window=7969796, just_this_one_p=0)
at xdisp.c:13266
#66 0x00069a28 in redisplay_window_0 (window=7969796) at xdisp.c:11871
#67 0x00154c10 in internal_condition_case_1 (bfun=0x699fc
<redisplay_window_0>, 
    arg=7969796, handlers=4659037, hfun=0x699dc
<redisplay_window_error>) at eval.c:1532
#68 0x000699c0 in redisplay_windows (window=7969796) at xdisp.c:11850
---Type <return> to continue, or q <return> to quit---
#69 0x00068e44 in redisplay_internal (preserve_echo_area=<value
optimized out>)
    at xdisp.c:11410
#70 0x000674f0 in redisplay () at xdisp.c:10626
#71 0x000ec6a0 in read_char (commandflag=1, nmaps=2, maps=0xffbedd40, 
    prev_event=4675585, used_mouse_menu=0xffbede00, end_time=0x0) at
keyboard.c:2675
#72 0x000f5aa0 in read_key_sequence (keybuf=0xffbedef0, bufsize=30,
prompt=4675585, 
    dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1)
    at keyboard.c:9152
#73 0x000ea1a0 in command_loop_1 () at keyboard.c:1621
#74 0x00154adc in internal_condition_case (bfun=0xe9e10
<command_loop_1>, 
    handlers=4743841, hfun=0xe96d8 <cmd_error>) at eval.c:1484
#75 0x000e9acc in command_loop_2 () at keyboard.c:1330
#76 0x00154588 in internal_catch (tag=4733953, func=0xe9aa0
<command_loop_2>, 
    arg=4675585) at eval.c:1224
#77 0x000e9a48 in command_loop () at keyboard.c:1309
#78 0x000e9418 in recursive_edit_1 () at keyboard.c:1007
#79 0x000e9584 in Frecursive_edit () at keyboard.c:1068
#80 0x000e82a4 in main (argc=2, argv=0xffbee43c) at emacs.c:1770

Lisp Backtrace:
"re-search-backward" (0x26300b)
"beginning-of-defun-raw" (0x475801)
"beginning-of-defun" (0x475801)
"c-get-fallback-start-pos" (0x3878)
"c-parse-state" (0x3fc)
"c-at-toplevel-p" (0x140)
"c-font-lock-declarators" (0x41f8)
0x6ca2e4 PVEC_COMPILED
"c-find-decl-spots" (0x41f8)
"c-font-lock-declarations" (0x41f8)
"font-lock-fontify-keywords-region" (0x31b8)
"font-lock-default-fontify-region" (0x31b8)
"font-lock-fontify-region" (0x31b8)
"run-hook-with-args" (0x6d5fc1)
"byte-code" (0x252b3b)
"jit-lock-fontify-now" (0x31b8)
"jit-lock-function" (0x31b8)
(gdb) 


 "Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. 
 
We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

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

Re: [22.1.90]: Point before start of properties

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 20 Feb 2008 12:17:01 -0500
> Cc: emacs-pretest-bug@gnu.org, Chong Yidong <cyd@stupidchicken.com>
> 
> 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, ...

So 20 years after GCC was a pioneer of the idea that it should be
possible to debug optimized code, we are back at printf debugging
because GCC developers no longer think it's important enough.
Progress, indeed...

To Simon: if compiling with -O1 does not give you reasonably
debuggable code, you may wish to look at the machine code at the
offending places.  For example, you might find out that, while
"p (((i)->up_obj || (i)->up.interval == 0))" yields zero, the real
values of up_obj and/or up.interval are loaded in registers, and thus
the condition does fire.  Although I find this rather surprising for
"-O1".

Btw, I'd also suggest to try "-ggdb -g3" instead of just -g, it should
cause GCC to produce more elaborate debug info, and could help you
discover real values of variables.

Re: [22.1.90]: Point before start of properties

[Richard Stallman]

    So 20 years after GCC was a pioneer of the idea that it should be
    possible to debug optimized code, we are back at printf debugging
    because GCC developers no longer think it's important enough.

I am the one who made it possible to debug optimized code.
And I did it in a very simple way: I deleted the statement that
turned off -g when -O was enabled.

It's one thing to let people try to debug optimized code,
and quite another to go to great lengths to make it easier.
GCC has never done that.

Re: [22.1.90]: Point before start of properties

[Stefan Monnier]

>     So 20 years after GCC was a pioneer of the idea that it should be
>     possible to debug optimized code, we are back at printf debugging
>     because GCC developers no longer think it's important enough.

> I am the one who made it possible to debug optimized code.
> And I did it in a very simple way: I deleted the statement that
> turned off -g when -O was enabled.

> It's one thing to let people try to debug optimized code,
> and quite another to go to great lengths to make it easier.
> GCC has never done that.

Debugging optimized code is an open research problem, fundamentally
very difficult.  Basically, it's an unsolvable problem,
i.e. a wrong question.


        Stefan

Re: [22.1.90]: Point before start of properties

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Debugging optimized code is [...] a wrong question.

Intel thanks you for your marketing of their future products!

[OT] Deugging optimized code (was: [22.1.90]: Point before start of properties)

[Stefan Monnier]

>> Debugging optimized code is [...] a wrong question.
> Intel thanks you for your marketing of their future products!

I guess I do, but I don't think you quite understood what I meant:
I indeed value correctness over speed (and really, Emacs is a good
example of low-speed program, both as a program (difficult to make it
fly) and as a language design&implementation); but my comment was
pointing out something else about "debugging optimized programs".
Basically such debugging comes up in a few different cases:

1 - the need to debug a program that is too-slow if not optimized.
2 - a bug in the compiler optimization phase.
3 - a bug that is depends on an unspecified behavior in the language,
    and which happens not to be triggered unless some optimization phase
    of the compiler is used.
4 - a timing-dependent bug.

Case 1 is best solved by using a different approach to debugging:
instead of a GDB-style approach (where the compiler does its thing
regardless of debugging and then the debugger is expected to be able to
present the result in a meaningful manner to the programmer), you can
take an Edebug-style approach where the *source* program is annotated
(maybe on the fly and then recompiled/reoptimized), in which case there
may not even be *any* need for "debugging-info" and the
compiler&optimizer can hence be made simpler and the debugger can be
(somewhat) independent from the compiler.  That's what I meant by "a
wrong question": instead of solving the impossible debugging problem
after-the-fact (after the optimizer has done its thing), you can solve
a different problem (annotate the source program) instead.

As for the other 3 situations, here's my take on it:
2 - use better software engineering technology, based on formal systems,
    to rule out these possibilities.  That's my area of research ;-)
3 - use a better specified language.
4 - There are all kinds of approaches to debug and/or formally verify
    race conditions.


        Stefan

Re: [OT] Deugging optimized code (was: [22.1.90]: Point before start of properties)

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Case 1 is best solved by using a different approach to debugging:
> instead of a GDB-style approach (where the compiler does its thing
> regardless of debugging and then the debugger is expected to be able to
> present the result in a meaningful manner to the programmer), you can
> take an Edebug-style approach where the *source* program is annotated
> (maybe on the fly and then recompiled/reoptimized),

Yes, ctrace(1), the future in debugging. :-)

Andreas.

http://www.freebsd.org/cgi/man.cgi?query=ctrace&apropos=0&sektion=1&manpath=SunOS+4.1.3&format=html

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[OT] Deugging optimized code (was: [22.1.90]: Point before start of properties)

[Stephen J. Turnbull]

Stefan Monnier writes:
 > >> Debugging optimized code is [...] a wrong question.
 > > Intel thanks you for your marketing of their future products!
 > 
 > I guess I do, but I don't think you quite understood what I meant:

Oh, I know more about what you do than you seem to think. ;-)  A
little bit, but that's enough.

 > That's what I meant by "a wrong question": instead of solving the
 > impossible debugging problem after-the-fact (after the optimizer
 > has done its thing), you can solve a different problem (annotate
 > the source program) instead.

First of all, this requires a reproducible problem.  That has two
issues: (1) maybe the problem isn't reproducible, and (2) for me at
least reproduction is a waste 90% of the time; the bugs I'm capable of
solving are typically apparent in the stack trace. :-)

Second, you're basically restricting the transformations that are
allowed to the translator.  This seems a reasonable strategy to me,
but it's not going to help with Type 2, 3, or 4 bugs, and it may
interfere with Type 1 bugs (eg, if you need to execute a loop a few
billion times to reach the buggy state -- proof of concept strawman).
More Intel The Next Generation promotion. :-)

So I wouldn't go so far as to say the question is "wrong", just that
there are better questions for a lot of debugging problems.

Re: [22.1.90]: Point before start of properties

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-pretest-bug@gnu.org,
>         Simon.Marshall@misys.com, cyd@stupidchicken.com
> Date: Thu, 21 Feb 2008 11:02:25 -0500
> 
> Debugging optimized code is an open research problem, fundamentally
> very difficult.  Basically, it's an unsolvable problem,
> i.e. a wrong question.

It can be solved almost trivially, IMO, by providing a special -Ox
switch which would turn off every optimization whose results cannot be
expressed reliably using the modern debug info formats.  The gain from
these optimizations is marginal anyway, on the order of several
percents, and many developers will gladly buy that if they gain
debuggability instead.

Re: [22.1.90]: Point before start of properties

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 21 Feb 2008 04:16:34 -0500
> Cc: emacs-pretest-bug@gnu.org, Simon.Marshall@misys.com,
> 	monnier@iro.umontreal.ca, cyd@stupidchicken.com
> 
> It's one thing to let people try to debug optimized code,
> and quite another to go to great lengths to make it easier.
> GCC has never done that.

Debugging GCC-optimized (under -O2) code is not just hard, it's
downright impossible!  In anything but the most trivial toy programs,
you end up with functions in which you cannot put a breakpoint,
tracebacks that cannot be trusted and which do not show values of some
variables in the calls to functions, variables whose values cannot be
displayed (except by disassemblying, and even then not everywhere),
and other ``niceties''.

The end result is what we hear in this list too many times: developers
run Emacs produced without optimizations, which means we don't test
well the code we eventually ship.

Re: [22.1.90]: Point before start of properties

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> It's one thing to let people try to debug optimized code,
>> and quite another to go to great lengths to make it easier.
>> GCC has never done that.
>
> Debugging GCC-optimized (under -O2) code is not just hard, it's
> downright impossible!

Oh, geez, stop with the exaggeration...  Sometimes it's maddening, other
times it's not a problem.

-Miles

-- 
We live, as we dream -- alone....

Re: [22.1.90]: Point before start of properties

[Richard Stallman]

    Debugging GCC-optimized (under -O2) code is not just hard, it's
    downright impossible!

This is unfortunate, but fixing it is very hard.  It would probably require
new ways to communcate info to GDB about the optimizations that were done,
and changes in GCC and GDB.

It would be great if someone implements these features, but there's no
use complaining that people have not done it.

    It can be solved almost trivially, IMO, by providing a special -Ox
    switch which would turn off every optimization whose results cannot be
    expressed reliably using the modern debug info formats.

Doesn't -O1 do that job?

Re: [22.1.90]: Point before start of properties

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 23 Feb 2008 14:29:31 -0500
> Cc: emacs-pretest-bug@gnu.org
> 
>     It can be solved almost trivially, IMO, by providing a special -Ox
>     switch which would turn off every optimization whose results cannot be
>     expressed reliably using the modern debug info formats.
> 
> Doesn't -O1 do that job?

No, not really.  -O1 disables ``expensive optimizations'',
i.e. optimizations that use significant portions of processor time.
Thus, which optimizations are selected for inclusion in -O1 has
nothing to do with which ones defeat debugging, and the fact that -O1
compiled programs are easier to debug is a pure coincidence.  I'm
quite sure several important optimizations could be added to -O1
without any significant effect on debuggability.

Re: [22.1.90]: Point before start of properties

[Richard Stallman]

    No, not really.  -O1 disables ``expensive optimizations'',
    i.e. optimizations that use significant portions of processor time.
    Thus, which optimizations are selected for inclusion in -O1 has
    nothing to do with which ones defeat debugging, and the fact that -O1
    compiled programs are easier to debug is a pure coincidence.  I'm
    quite sure several important optimizations could be added to -O1
    without any significant effect on debuggability.

In practice, though, does it really make a difference?
Why won't using -O1 be good for you?
Do you really need the extra performance of those
optimizations that could be added?

Re: [22.1.90]: Point before start of properties

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: emacs-pretest-bug@gnu.org
> Date: Sun, 24 Feb 2008 10:22:46 -0500
> 
> Why won't using -O1 be good for you?
> Do you really need the extra performance of those
> optimizations that could be added?

Yes, I need all the extra performance I can get, since the fact that
"-O2" gives code that cannot be debugged reliably means that I have to
ship software compiled with "-O1" (because I'm unwilling to ship code
I didn't test, and I don't want to test code I cannot debug).

Re: [22.1.90]: Point before start of properties

[Richard Stallman]

    Yes, I need all the extra performance I can get, since the fact that
    "-O2" gives code that cannot be debugged reliably means that I have to
    ship software compiled with "-O1" (because I'm unwilling to ship code
    I didn't test, and I don't want to test code I cannot debug).

I suggest you make a specific proposal and send it to the GCC
discussion list.  The option could be called -Odebug, but the real
issue is to decide which optimizations to include.

Re: [22.1.90]: Point before start of properties

[Stefan Monnier]

>     Yes, I need all the extra performance I can get, since the fact that
>     "-O2" gives code that cannot be debugged reliably means that I have to
>     ship software compiled with "-O1" (because I'm unwilling to ship code
>     I didn't test, and I don't want to test code I cannot debug).

> I suggest you make a specific proposal and send it to the GCC
> discussion list.  The option could be called -Odebug, but the real
> issue is to decide which optimizations to include.

Maybe a better approach would be a "-really-g" that would disable all
problematic optimizations.  So it can be combined with -O9 or some such
super-expensive optimization (expensive but whose result is not hard to
describe to GDB).


        Stefan

Re: [22.1.90]: Point before start of properties

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

rms> This is unfortunate, but fixing it is very hard.  It would probably require
rms> new ways to communcate info to GDB about the optimizations that were done,
rms> and changes in GCC and GDB.

There's some work going on now that may address this, at least a bit.
There are two different branches, implementing different approaches to
the problem.  Here's info about one:

http://gcc.gnu.org/wiki/Var_Tracking_Assignments

The other is called "var-mappings-branch" and does not appear to have
a wiki page.

Tom

Re: [22.1.90]: Point before start of properties

[Richard Stallman]

    rms> This is unfortunate, but fixing it is very hard.  It would probably require
    rms> new ways to communcate info to GDB about the optimizations that were done,
    rms> and changes in GCC and GDB.

    There's some work going on now that may address this, at least a bit.

It sounds useful.

Re: [22.1.90]: Point before start of properties

[Richard Stallman]

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

I think this is enough to file a GCC bug report.  The GCC developers
can compare the assembler code with the C code and precisely identify
the bug.

RE: [22.1.90]: Point before start of properties

[Marshall, Simon]

I've opened a gcc bug on this at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35249 but any thoughts or
suggestions are still welcome.

-----Original Message-----
From: Marshall, Simon 
Sent: 19 February 2008 10:38
To: 'Stefan Monnier'
Cc: 'Chong Yidong'; 'emacs-pretest-bug@gnu.org'
Subject: RE: [22.1.90]: Point before start of properties

Thanks for the suggestions and the careful reading of my report.  Is
there anything else you think I could try, eg, to deal with the size of
struct interval?  I can confirm that it is 28, though it is 28 with or
without optimisation.  I tried padding it to 32 by adding a dummy int to
it, but it still hit the breakpoint with optimisation.

I don't like the thought of trying to break up intervals.c, to binary
search for a particular problem function, so any other suggestions are
welcome.

Simon.



 "Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners. 
 
We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

Re: [22.1.90]: Point before start of properties

[Richard Stallman]

    I don't like the thought of trying to break up intervals.c, to binary
    search for a particular problem function, so any other suggestions are
    welcome.

Please use the binary search method if you don't find another way.

The only other method I know of is to debug the problem and localize
the incorrect execution to a particular piece of code.  By comparison,
the binary search method is much easier.

Re: [22.1.90]: Point before start of properties

[Richard Stallman]

The error "point before start of properties" could just as well
be an abort, since it reports a condition that should be impossible.
Namely, that the interval data structure that records the text properties
is invalid, in that it does not cover the whole of the buffer.

The first step in debugging this is to carefully examine the interval
data structure and see how it is invalid.

The next step is to see how it got that way.
Your simple test case should make that fairly easy:

    (gdb) b intervals.c:794
    Breakpoint 1 at 0x195d90: file intervals.c, line 794.
    (gdb) r -Q

    Then in emacs do C-x C-f ~/.../src/intervals.c RET and bang:

    Breakpoint 1, update_interval (i=0x8b1af4, pos=1771) at intervals.c:794
    794                 error ("Point before start of properties");
    (gdb) 

Does anyone else observe this bug?