March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: crash when using W3 24 years, 8 months

William M. Perry

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > > > ... what happens when the buffer gets killed during the loop? > > You lose. I didn't really pay much attention to that case, > considering it highly extreme and even contrived. I was probably > wrong. > > How do we get in the situation where after-change-functions kill the > buffer? Can that really be intentional? Yup... I do (well, did) it in Emacs/W3 - the source comes in from an HTTP request, we parse it, kill that buffer, draw in a new buffer. Ran into all sorts of oddities trying to kill that buffer from within the a-c-f. So I just throw it on a list and just delete all buffers on the list next time you come thru the url functions. -bp

1 participants
0 comments

Re: motion screwiness in latest cvs 24 years, 8 months

Jan Vroonhof

Jeff Miller <jmiller(a)smart.net> writes: > i'm running the latest cvs of 21.2. Try updating again. Yoshiki has reverted the part from Andy's patch that is supposedly causing all this. Jan

1 participants
0 comments

Re: crash when using W3 24 years, 8 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > ... what happens when the buffer gets killed during the loop? You lose. I didn't really pay much attention to that case, considering it highly extreme and even contrived. I was probably wrong. How do we get in the situation where after-change-functions kill the buffer? Can that really be intentional? > Footnotes: > [1] Actually by another a-c-f running because an lisp event came in > that triggered insertions in another buffer.! At one time I considered modifying inside_change_hook to be a per-buffer flag. Currently, if an after/before-change function writes to *another* buffer, the *other* buffer's after/before-change function won't get run. That's wrong.

1 participants
0 comments

GC bug 24 years, 8 months

Andy Piper

Well I can reproduce one of the GC problems we are having: ./xemacs -q C-x C-f gutter-items.el M-x garbage-collect If you then try clicking on a tab nothing happens because the callback has been garbage collected. No time to investigate - I have to go and see the acropolis. I'll see if I can figure it out on the plane on the way back andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Could someone fix modeline shadow redisplay glitches? 24 years, 8 months

Martin Buchholz

Try this: (set-specifier modeline-shadow-thickness 10) ; to accentuate the negative Now try obscuring just the modeline shadow (not the main part of the modeline) and re-expose it. The modeline shadow is not redrawn in response to the expose event. Related bug: Do M-x ispell-buffer. See how the ispell *Choices* buffer is mostly obscured by the modeline shadow, making the *Choices* buffer useless. Perhaps Andy or Jan could fix this?

1 participants
0 comments

Re: undefine key binding 24 years, 8 months

Jan Vroonhof

Michael Harnois <mdharnois(a)home.com> writes: > > (define-key bbdb-mode-map "\M-\t" 'bbdb-complete-name) > > in .emacs would do it, but I seem to have been wrong. Flyspell is a minor mode so the keymap always priority. I don't think there is an easy way out here, short of removing the binding from fly-spell altogether. Jan

1 participants
0 comments

Re: crash when using W3 24 years, 8 months

Jan Vroonhof

I nailed it! Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > #7 0x8122e65 in signal_after_change (buf=0x857e6b8, start=0, orig_end=1, > > new_end=0) at /scratch/vroonhof/xemacs/src/insdel.c:2291 > > I don't understand how start ends up being 0, short of a memory > corruption. The trace is actually correct! It turns out that the buffer was deleted by lisp code during the after_change_functions[1]. W3's fancy async stuff uses the a-c-f a lot for nontrivial stuff. The whole page is rendered in an a-c-f! The patch at end fixes the crash (but I still get a buffer-live-p lisp error from somewhere). I think that whole code should be audited for race conditions.... > > P.S. Shouldn't bufcons and buffer be gcproed? > > I don't think so. bufcons maps over the list of indirect children, > which is GC-safe. ... what happens when the buffer gets killed during the loop? Doesn't that loose the head of the list? etc etc.. Jan Footnotes: [1] Actually by another a-c-f running because an lisp event came in that triggered insertions in another buffer.! Index: insdel.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/insdel.c,v retrieving revision 1.19.2.12 diff -u -u -r1.19.2.12 insdel.c --- insdel.c 2000/02/19 09:24:54 1.19.2.12 +++ insdel.c 2000/03/18 00:36:16 ＠＠ -2276,20 +2276,29 ＠＠ } } - /* Make sure endpoints remain valid. after-change-functions - might have modified the buffer. */ - if (start < BUF_BEGV (buf)) start = BUF_BEGV (buf); - if (start > BUF_ZV (buf)) start = BUF_ZV (buf); - if (new_end < BUF_BEGV (buf)) new_end = BUF_BEGV (buf); - if (new_end > BUF_ZV (buf)) new_end = BUF_ZV (buf); - if (orig_end < BUF_BEGV (buf)) orig_end = BUF_BEGV (buf); - if (orig_end > BUF_ZV (buf)) orig_end = BUF_ZV (buf); + /* after-change-functions run lisp. Anything could have + happened (if not by a poor innocent a-c-f then by some + lisp triggered by an event) */ - MAP_INDIRECT_BUFFERS (buf, mbuf, bufcons) - { - XSETBUFFER (buffer, mbuf); - report_extent_modification (buffer, start, new_end, 1); - } + /* buffer could have disappeared from under us ! */ + + if (BUFFER_LIVE_P(buf)) + { + /* Make sure endpoints remain valid. after-change-functions + might have modified the buffer. */ + if (start < BUF_BEGV (buf)) start = BUF_BEGV (buf); + if (start > BUF_ZV (buf)) start = BUF_ZV (buf); + if (new_end < BUF_BEGV (buf)) new_end = BUF_BEGV (buf); + if (new_end > BUF_ZV (buf)) new_end = BUF_ZV (buf); + if (orig_end < BUF_BEGV (buf)) orig_end = BUF_BEGV (buf); + if (orig_end > BUF_ZV (buf)) orig_end = BUF_ZV (buf); + + MAP_INDIRECT_BUFFERS (buf, mbuf, bufcons) + { + XSETBUFFER (buffer, mbuf); + report_extent_modification (buffer, start, new_end, 1); + } + } unbind_to (speccount, Qnil); /* sets inside_change_hook back to 0 */ } }

1 participants
0 comments

Re: crash when using W3 24 years, 8 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > #7 0x8122e65 in signal_after_change (buf=0x857e6b8, start=0, orig_end=1, > > new_end=0) at /scratch/vroonhof/xemacs/src/insdel.c:2291 > > I don't understand how start ends up being 0, short of a memory > corruption. It is even more weird than that... Look at the following session and stand in awe... It some how coming back to a change it did earlier! However the buffer that it pertains to is no longer life and kaboom...! Note how frame #9 in the crash trace equals the situation at the first time it hit the break point! Starting program: /scratch/vroonhof/xemacs/debug/src/xemacs (gdb) break buffer_insert_string_1 Breakpoint 2 at 0x8123187: file /scratch/vroonhof/xemacs/src/insdel.c, line 2423. (gdb) cond 2 (length == 1024) (gdb) c Continuing. Breakpoint 2, buffer_insert_string_1 (buf=0x855e3f0, pos=-1, nonreloc=0xbfffed00 "HTTP/1.1 200 OK\r\nDate: Fri, 17 Mar 2000 23:37:25 GMT\r\nServer: Apache/1.3.3 (Unix) mod_perl/1.16\r\nLast-Modified: Fri, 17 Dec 1999 14:10:50 GMT\r\nETag: \"1f26-915-385a446a\"\r\nAccept-Ranges: bytes\r\nContent-"..., reloc=136717252, offset=0, length=1024, flags=0) at /scratch/vroonhof/xemacs/src/insdel.c:2423 (gdb) c Continuing. Breakpoint 2, buffer_insert_string_1 (buf=0x855e3f0, pos=-1, nonreloc=0xbfffe1d0 "5\">Gruppe 5</a>) office at <TT>+41-1-63 25 456/ 25 154</TT> </LI>\n\n<LI>or fax at <TT>+41-1-63 21085</TT>. </LI>\n\n<LI>In last resort send snail mail to: \n\t<p class=\"adres\">Jan Vroonhof <BR>\n\t <A HRE"..., reloc=136717252, offset=0, length=1024, flags=0) at /scratch/vroonhof/xemacs/src/insdel.c:2423 (gdb) c Continuing. Breakpoint 2, buffer_insert_string_1 (buf=0x885a3d0, pos=-1, nonreloc=0xbfffcfd8 "HTTP/1.1 200 OK\r\nDate: Fri, 17 Mar 2000 23:37:42 GMT\r\nServer: Apache/1.3.6 (Unix) PHP/3.0.15\r\nContent-Location: Ultramarine.css\r\nVary: negotiate\r\nTCN: choice\r\nConnection: close\r\nContent-Type: text/css"..., reloc=136717252, offset=0, length=1024, flags=0) at /scratch/vroonhof/xemacs/src/insdel.c:2423 (gdb) c Continuing. Breakpoint 2, buffer_insert_string_1 (buf=0x885a3d0, pos=-1, nonreloc=0xbfffcfd8 ", H1, H2, H3, H4, H5, H6, IFRAME, IMG, KBD,\t\t\nLI, OBJECT, OL, P, Q, SAMP, SMALL, SPAN, STRONG, SUB, SUP, UL, VAR, \t\t\nAPPLET, BIG, CENTER, DIR, FONT, HR, MENU, PRE,\t\t\nABBR, ACRONYM, BDO, BUTTON, FIELDS"..., reloc=136717252, offset=0, length=1024, flags=0) at /scratch/vroonhof/xemacs/src/insdel.c:2423 (gdb) c Continuing. Breakpoint 2, buffer_insert_string_1 (buf=0x885a3d0, pos=-1, nonreloc=0xbfffcfd8 "060;\n\t}\t\n\t\t\nVAR, CITE, DFN, .note\t{\t\n\tfont-style:\titalic;\n\t}\t\n\t\t\nADDRESS\t{\t\n\tfont-style:\tnormal;\n\tletter-spacing:\t.1em;\n\t}\t\n\t\t\nACRONYM\t{\t\n\tfont-variant:\tsmall-caps;\n\tletter-spacing:\t0.1em;\n\t}\t\n\t\t\nH1, "..., reloc=136717252, offset=0, length=1024, flags=0) at /scratch/vroonhof/xemacs/src/insdel.c:2423 (gdb) cont Continuing. Fatal error: assertion failed, file /scratch/vroonhof/xemacs/src/insdel.c, line 1116, BUFFER_LIVE_P (buf) Program received signal SIGABRT, Aborted. 0x403174e1 in __kill () from /lib/libc.so.6 (gdb) where #3 0x80aac73 in assert_failed ( file=0x81ec1e0 "/scratch/vroonhof/xemacs/src/insdel.c", line=1116, expr=0x81ebab6 "BUFFER_LIVE_P (buf)") at /scratch/vroonhof/xemacs/src/emacs.c:2753 #4 0x8121227 in bufpos_to_bytind (buf=0x855e3f0, x=0) at /scratch/vroonhof/xemacs/src/insdel.c:1116 #5 0x80e27af in map_extents (from=0, to=0, fn=0x80e6df8 <report_extent_modification_mapper>, arg=0xbfffebdc, obj=139846640, after=0x0, flags=15360) at /scratch/vroonhof/xemacs/src/extents.c:2283 #6 0x80e7046 in report_extent_modification (buffer=139846640, start=0, end=0, afterp=1) at /scratch/vroonhof/xemacs/src/extents.c:4700 #7 0x8122e65 in signal_after_change (buf=0x855e3f0, start=0, orig_end=1, new_end=0) at /scratch/vroonhof/xemacs/src/insdel.c:2291 #8 0x812391d in buffer_insert_string_1 (buf=0x855e3f0, pos=1, nonreloc=0xbfffed00 "HTTP/1.1 200 OK\r\nDate: Fri, 17 Mar 2000 23:37:25 GMT\r\nServer: Apache/1.3.3 (Unix) mod_perl/1.16\r\nLast-Modified: Fri, 17 Dec 1999 14:10:50 GMT\r\nETag: \"1f26-915-385a446a\"\r\nAccept-Ranges: bytes\r\nContent-"..., reloc=136717252, offset=0, length=1024, flags=0) at /scratch/vroonhof/xemacs/src/insdel.c:2564 #9 0x812394f in buffer_insert_raw_string_1 (buf=0x855e3f0, pos=-1, nonreloc=0xbfffed00 "HTTP/1.1 200 OK\r\nDate: Fri, 17 Mar 2000 23:37:25 GMT\r\nServer: Apache/1.3.3 (Unix) mod_perl/1.16\r\nLast-Modified: Fri, 17 Dec 1999 14:10:50 GMT\r\nETag: \"1f26-915-385a446a\"\r\nAccept-Ranges: bytes\r\nContent-"..., length=1024, flags=0) at /scratch/vroonhof/xemacs/src/insdel.c:2584 #10 0x813cf97 in read_process_output (proc=142837440) at /scratch/vroonhof/xemacs/src/process.c:921 #11 0x80dd15d in execute_internal_event (event=139837392) at /scratch/vroonhof/xemacs/src/event-stream.c:2953 #12 0x80dece6 in Fdispatch_event (event=139837392) at /scratch/vroonhof/xemacs/src/event-stream.c:4207 #13 0x8095bbb in Fcommand_loop_1 () at /scratch/vroonhof/xemacs/src/cmdloop.c:575 #14 0x80959fd in command_loop_1 (dummy=136717252) at /scratch/vroonhof/xemacs/src/cmdloop.c:490 #15 0x80ad88a in condition_case_1 (handlers=136717348, bfun=0x80959c4 <command_loop_1>, barg=136717252, hfun=0x8095194 <cmd_error>, harg=136717252) at /scratch/vroonhof/xemacs/src/eval.c:1644 #16 0x809526c in command_loop_3 () at /scratch/vroonhof/xemacs/src/cmdloop.c:252 #17 0x8095288 in command_loop_2 (dummy=136717252) at /scratch/vroonhof/xemacs/src/cmdloop.c:263 #18 0x80ad4a9 in internal_catch (tag=136789060, func=0x8095280 <command_loop_2>, arg=136717252, threw=0x0) at /scratch/vroonhof/xemacs/src/eval.c:1310 #19 0x80954fd in initial_command_loop (load_me=136717252) at /scratch/vroonhof/xemacs/src/cmdloop.c:301 #20 0x80a9e62 in xemacs_21_2_b31_i686_pc_linux (argc=1, argv=0xbffff464, envp=0xbffff46c, restart=0) at /scratch/vroonhof/xemacs/src/emacs.c:1872 #21 0x80aa5b8 in voodoo_free_hook (mem=0x1) at /scratch/vroonhof/xemacs/src/emacs.c:2291 #22 0x403111eb in __libc_start_main (main=0x80aa4c4 <main>, argc=1, argv=0xbffff464, init=0x807dc24 <_init>, fini=0x81a8220 <_fini>, rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbffff45c) at ../sysdeps/generic/libc-start.c:90 This is actually repeatable.... Here another trace #8 0x812391d in buffer_insert_string_1 (buf=0x857e9c0, pos=1, nonreloc=0xbfffed00 "HTTP/1.1 200 OK\r\nDate: Fri, 17 Mar 2000 23:40:19 GMT\r\nServer: Apache/1.3.3 (Unix) mod_perl/1.16\r\nLast-Modified: Fri, 17 Dec 1999 14:10:50 GMT\r\nETag: \"1f26-915-385a446a\"\r\nAccept-Ranges: bytes\r\nContent-"..., reloc=136717252, offset=0, length=1024, flags=0) at /scratch/vroonhof/xemacs/src/insdel.c:2564 #9 0x812394f in buffer_insert_raw_string_1 (buf=0x857e9c0, pos=-1, nonreloc=0xbfffed00 "HTTP/1.1 200 OK\r\nDate: Fri, 17 Mar 2000 23:40:19 GMT\r\nServer: Apache/1.3.3 (Unix) mod_perl/1.16\r\nLast-Modified: Fri, 17 Dec 1999 14:10:50 GMT\r\nETag: \"1f26-915-385a446a\"\r\nAccept-Ranges: bytes\r\nContent-"..., length=1024, flags=0) at /scratch/vroonhof/xemacs/src/insdel.c:2584 #10 0x813cf97 in read_process_output (proc=142842688) at /scratch/vroonhof/xemacs/src/process.c:921 (gdb) frame 10 #10 0x813cf97 in read_process_output (proc=142842688) at /scratch/vroonhof/xemacs/src/process.c:921 (gdb) pobj proc $5 = (Lisp_Process *) 0x8839b40 $6 = {header = {lheader = {type = 16, mark = 0, c_readonly = 0, lisp_readonly = 0}, next = 0x8838978, uid = 17345, free = 0}, name = 142070052, command = 136717252, filter = 136717252, sentinel = 141043484, buffer = 139979200, mark = 136980820, pid = 142824148, status_symbol = 136803156, exit_code = 256, core_dumped = 0 '\000', filter_does_read = 0 '\000', kill_without_query = 1 '\001', selected = 0 '\000', tick = 1, update_tick = 1, pipe_instream = 136717252, pipe_outstream = 136717252, process_data = 0x881de50} (gdb) print $6.buffer $7 = 139979200 (gdb) pobj $7 $8 = (struct buffer *) 0x857e9c0 $9 = {header = {lheader = {type = 24, mark = 0, c_readonly = 0, lisp_readonly = 0}, next = 0x857e520, uid = 17291, free = 0}, own_text = {beg = 0x0, gpt = 0, z = 0, bufz = 0, gap_size = 0, end_gap_size = 0, modiff = 0, save_modiff = 0, line_number_cache = 136717252, changes = 0x0}, text = 0x0, pt = 0, bufpt = 0, begv = 0, bufbegv = 0, zv = 0, bufzv = 0, face_change = 0, changes = 0x0, markers = 0x0, extent_info = 136717252, base_buffer = 0x0, indirect_children = 136717252, local_var_flags = 0, modtime = 0, auto_save_modified = 0, auto_save_failure_time = 0, last_window_start = 0, name = 136717252, filename = 136717252, directory = 136717252, backed_up = 136717252, saved_size = 136717252, auto_save_file_name = 136717252, read_only = 136717252, mark = 136717252, local_var_alist = 136717252, major_mode = 136717252, mode_name = 136717252, modeline_format = 136717252, keymap = 136717252, abbrev_table = 136717252, syntax_table = 136717252, mirror_syntax_table = 136717252, case_fold_search = 136717252, tab_width = 136717252, fill_column = 136717252, left_margin = 136717252, auto_fill_function = 136717252, downcase_table = 136717252, upcase_table = 136717252, case_canon_table = 136717252, case_eqv_table = 136717252, truncate_lines = 136717252, ctl_arrow = 136717252, selective_display = 136717252, selective_display_ellipses = 136717252, overwrite_mode = 136717252, abbrev_mode = 136717252, undo_list = 136717252, dedicated_frame = 136717252, file_format = 136717252, point_marker = 136717252, point_before_scroll = 136717252, file_truename = 136717252, invisibility_spec = 136717252, generated_modeline_string = 136717252, modeline_extent_table = 136717252} (gdb) print $9.name $10 = 136717252 (gdb) pobj $10 $11 = (Lisp_Symbol *) 0x82623c4 $12 = {lheader = {type = 4, mark = 0, c_readonly = 0, lisp_readonly = 0}, next = 0x0, name = 0x8261bcc, value = 136717252, function = 136329004, plist = 136717252} Symbol name: nil (gdb) pobj $12.name $13 = (Lisp_String *) 0x8261bcc $14 = {lheader = {type = 8, mark = 1, c_readonly = 1, lisp_readonly = 1}, size = 3, data = 0x8203740 "nil", plist = 136717252} (gdb)

1 participants
0 comments

Re: Pixel-based scrolling mystery 24 years, 8 months

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > Try clicking on the scrollbar arrows instead of dragging. I assume that > dragging doesn't kick in the support for some reason. I never figured out why. See my other message to Hrvoje. scrollbar-drag does not do window scroll, it does a set-window-start directly.. Jan

1 participants
0 comments

undefine key binding 24 years, 8 months

Michael Harnois

How do I undo flyspell's stealing of M-tab from bbdb? I can see how to do it by brute force by removing it from flyspell.el, but I'm sure there's a right way, I just seem to be too stupid to figure it out. I thought putting (define-key bbdb-mode-map "\M-\t" 'bbdb-complete-name) in .emacs would do it, but I seem to have been wrong. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois(a)home.com aa0bt(a)aa0bt.ampr.org The first thing you should do when you get up is read the obituaries. You never know when you'll see a name that will just make your day. --Ed Salisbury

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta March 2000