[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [22.1.90]: Point before start of properties
From: |
Marshall, Simon |
Subject: |
RE: [22.1.90]: Point before start of properties |
Date: |
Tue, 19 Feb 2008 17:23:08 -0000 |
> > 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.
- [22.1.90]: Point before start of properties, Marshall, Simon, 2008/02/08
- Re: [22.1.90]: Point before start of properties, Stefan Monnier, 2008/02/09
- Re: [22.1.90]: Point before start of properties, Chong Yidong, 2008/02/10
- RE: [22.1.90]: Point before start of properties, Marshall, Simon, 2008/02/12
- Re: [22.1.90]: Point before start of properties, Stefan Monnier, 2008/02/12
- RE: [22.1.90]: Point before start of properties, Marshall, Simon, 2008/02/13
- Re: [22.1.90]: Point before start of properties, Stefan Monnier, 2008/02/18
- RE: [22.1.90]: Point before start of properties, Marshall, Simon, 2008/02/19
- Re: [22.1.90]: Point before start of properties, Stefan Monnier, 2008/02/19
- RE: [22.1.90]: Point before start of properties,
Marshall, Simon <=
- Re: [22.1.90]: Point before start of properties, David Kastrup, 2008/02/19
- RE: [22.1.90]: Point before start of properties, Marshall, Simon, 2008/02/20
- Re: [22.1.90]: Point before start of properties, Stefan Monnier, 2008/02/19
- RE: [22.1.90]: Point before start of properties, Marshall, Simon, 2008/02/20
- Re: [22.1.90]: Point before start of properties, Stefan Monnier, 2008/02/20
- Re: [22.1.90]: Point before start of properties, Eli Zaretskii, 2008/02/20
- Re: [22.1.90]: Point before start of properties, Richard Stallman, 2008/02/21
- Re: [22.1.90]: Point before start of properties, Stefan Monnier, 2008/02/21
- Re: [22.1.90]: Point before start of properties, Stephen J. Turnbull, 2008/02/21
- [OT] Deugging optimized code (was: [22.1.90]: Point before start of properties), Stefan Monnier, 2008/02/22