The following message is a courtesy copy of an article
that has been posted to gmane.emacs.xemacs.beta as well.
Hi Stephen
BTW: Upgrading to 21.5.30 didn't change the situation.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
C-h i d m "Internals" RET
Thanks, found it.
> Especially the macros seem scary. It doesn't help that
running my
> self-compiled XEmacs under GDB (Ubuntu) will segfault in
> memset()...
Can you give us a backtrace for that?
Weird. Starting "gdb -x src/.gdbinit src/xemacs" doesn't cause a crash,
but opens a frame instead and the inferior XEmacs seems to behave.
Without loading .gdbinit, I won't get a frame and gdb gives me this
backtrace:
,----[ gdb src/xemacs ]
| (gdb) r
| Starting program: /home/marcus/projekte/xemacs-beta-compile/src/xemacs
| [Thread debugging using libthread_db enabled]
|
| Program received signal SIGSEGV, Segmentation fault.
| memset () at ../sysdeps/x86_64/memset.S:334
| 334 ../sysdeps/x86_64/memset.S: No such file or directory.
| in ../sysdeps/x86_64/memset.S
| (gdb) bt
| #0 memset () at ../sysdeps/x86_64/memset.S:334
| #1 0x00000000005e2674 in mc_alloc_1 (size=48, elemcount=1) at mc-alloc.c:1647
| #2 0x00000000005e2720 in mc_alloc (size=48) at mc-alloc.c:1671
| #3 0x0000000000457005 in alloc_sized_lrecord_1 (size=48,
| implementation=0x9a19c0, noseeum=0) at alloc.c:606
| #4 0x00000000004571f2 in alloc_sized_lrecord (size=48,
| implementation=0x9a19c0) at alloc.c:625
| #5 0x0000000000457241 in alloc_lrecord (implementation=0x9a19c0)
| at alloc.c:640
| #6 0x0000000000458e12 in Fmake_marker () at alloc.c:2333
| #7 0x00000000005e03bf in make_lisp_buffer_stream_1 (buf=0xd83590, start=1,
| end=2, flags=0, mode=0x736df1 "r") at lstream.c:1686
| #8 0x00000000005e04c6 in make_lisp_buffer_input_stream (buf=0xd83590,
| start=1, end=2, flags=0) at lstream.c:1710
| #9 0x000000000051cd6c in encode_decode_coding_region (start=3, end=5,
| coding_system=30923728, buffer=28125632, direction=CODING_DECODE)
| at file-coding.c:2221
| #10 0x000000000051d104 in Fdecode_coding_region (start=3, end=5,
| coding_system=28125632, buffer=28125632) at file-coding.c:2317
| #11 0x00000000004cc95d in Ffuncall (nargs=4, args=0x7fffffffb3f8)
| at eval.c:4103
| #12 0x000000000046d44b in execute_optimized_program (
| program=0x1d914f0 "\303\304\305!!\032Ǝr\nq\210\tc\210\307ed\b#\210\310
+\20----Type <return> to continue, or q <return> to quit---q
| Quit
| (gdb) quit
`----
In any case, I can debug now and will try to find the root cause of my
actual problem. I am fairly convinced now that #'skip-syntax-forward is
not picking up the syntax class change applied by syntactic
font-lock. It thinks it were looking at two interleaved sexps and gives
up. Well, we'll see...
--
Marcus
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta