March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Jan Vroonhof

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Grimly I point out that if we ignored recording changes until > redisplay was called and then compared old state to new state it > would make little difference what lazy-lock did. That is what the code has been doing since a few days. It works quite well (i.e. lisp updates a copy of the tab widgets and redisplay copies that if that and the displayed version no longer match). Of course, no matter what lisp is doing, XEmacs shouldn't crash. This is not about the displayed state being update to match lisp. This about running lisp code that needs to track the state of the selected window. It must be run also inside a save-window-configuration because the code would very well be (save-window-configuration (select-window w) (recursive-edit)..) However it turns out everybody and his dog is using the (save-window-configuration (select-window w) idiom.. This is suggests two things... 1. record-buffer-hook is called way to often to do expensive things. The solution is standard. Change the hook to simply set a flag and then put the real update function at some other point that is less expensive (pre-idle-hook? There isn't a pre-redisplay-hook that I can see).[1] 2. save-window-configuration is expensive. If so much code needs to do it there is probably something missing in the api. Some functions need window arguments? Footnotes: [1] It could be you meant this in the first place. But then I disagree with the statement that is as is always been for lisp, because the appropriate hooks seem to be missing.

2 participants
1 comments

Re: nasty crash 24 years, 10 months

Gunnar Evermann

Raymond Toy <toy(a)rtp.ericsson.se> writes: > Gunnar> Maybe we (and especially Raymond) can try running with the following > Gunnar> (untested) patch. Any backtraces might give new hints. > > I tried this patch. With ./xemacs -vanilla, when I try M-x load-lib > RET, xemacs crashes exactly in the assert statement you added. yes, that was the idea. In the meantime I have realised that this was slightly too simplistic, this will get triggered easily from unwind_to_catch (which normally removes the entries from the catchlist itself)... Sorry, I have no more time right now. We have an important project deadline at midnight... Gunnar

1 participants
0 comments

Re: nasty crash 24 years, 10 months

Raymond Toy

>>>>> "Gunnar" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: Gunnar> Yes that's my best guess at the moment as well, especially since Gunnar> Raymond's backtraces seem to indicate that one element in the Gunnar> catchlist is corrupted and involve Fthrow (and just about every other Gunnar> non-trivial function in XEmacs). Gunnar> Maybe we (and especially Raymond) can try running with the following Gunnar> (untested) patch. Any backtraces might give new hints. I tried this patch. With ./xemacs -vanilla, when I try M-x load-lib RET, xemacs crashes exactly in the assert statement you added. Note that this test still has the debug-on-entry in my .eudc-options file. Also note that the elc files for eudc were compiled using 21.1.9 because I wasn't sure if 21.1.9 could use files compiled by 21.2.31. No lisp backtrace, but the C backtrace appended. Ray #0 0xfec16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xfebb92e0 in abort () from /usr/lib/libc.so.1 #2 0xa6598 in assert_failed (file=0x241058 "eval.c", line=4640, expr=0x241298 "0") at emacs.c:2770 #3 0xb05d0 in unbind_to_hairy (count=41) at eval.c:4640 #4 0xb0468 in unbind_to (count=41, value=3028996) at eval.c:4590 #5 0x7339c in dfc_convert_to_external_format (source_type=4290691745, source=0xffbec2a1, coding_system=32, sink_type=DFC_TYPE_DATA, sink=0xffbec220) at buffer.c:2000 #6 0x180fb8 in write_string_to_stdio_stream (stream=0x2bb9b8, con=0x0, str=0xffbec2a0 " <¬V", offset=0, len=1, coding_system=3158764) at print.c:117 #7 0x184908 in Fexternal_debugging_output (char_or_string=130, stdout_p=3028996, device=2865592) at print.c:1472 #8 0xad5cc in Ffuncall (nargs=-1, args=0xffbec3c8) at eval.c:3175 #9 0xae7cc in call1 (fn=3172380, arg0=130) at eval.c:3824 #10 0x18161c in output_string (function=3172380, nonreloc=0x241348 " ", reloc=3028996, offset=0, len=2) at print.c:251 #11 0x1818ec in write_c_string (str=0x241348 " ", stream=3172380) at print.c:369 #12 0xb0a88 in Fbacktrace (stream=3172380, detailed=3029020) at eval.c:4819 #13 0xa3860 in fatal_error_signal (sig=6) at emacs.c:255 #14 <signal handler called> #15 0xfec16870 in _libc_kill () from /usr/lib/libc.so.1 #16 0xfebb92a4 in abort () from /usr/lib/libc.so.1 #17 0xa6598 in assert_failed (file=0x241058 "eval.c", line=4640, expr=0x241298 "0") at emacs.c:2770 #18 0xb05d0 in unbind_to_hairy (count=41) at eval.c:4640 #19 0xb0468 in unbind_to (count=41, value=3028996) at eval.c:4590 #20 0xa93b0 in Fthrow (tag=3125276, val=3028996) at eval.c:1367 #21 0xad5b4 in Ffuncall (nargs=2, args=0xffbecd14) at eval.c:3175 #22 0x787e8 in execute_optimized_program (program=0xffbecd14 "", stack_depth=2, constants_data=0x492f90) at bytecode.c:747 #23 0x78048 in funcall_compiled_function (fun=4788620, nargs=0, args=0xffbecfd0) at bytecode.c:519 #24 0xad780 in Ffuncall (nargs=0, args=0xffbecfcc) at eval.c:3210 #25 0xae740 in apply1 (fn=4788620, arg=3028996) at eval.c:3793 #26 0x7d0e8 in Fcall_interactively (function=4758108, record_flag=3028996, keys=3028996) at callint.c:394 #27 0xabfa8 in Fcommand_execute (cmd=4758108, record=3028996, keys=3028996) at eval.c:2613 #28 0x10045c in execute_command_event (command_builder=0x635a80, event=6861732) at event-stream.c:4333 #29 0x100da0 in Fdispatch_event (event=6861732) at event-stream.c:4644 #30 0x87718 in Fcommand_loop_1 () at cmdloop.c:575 #31 0x874ac in command_loop_1 (dummy=3028996) at cmdloop.c:490 #32 0xa9764 in condition_case_1 (handlers=2807808, bfun=0x87460 <command_loop_1>, barg=3028996, hfun=0x878f8 <cmd_error>, harg=3028996) at eval.c:1629 #33 0x86e68 in call_command_loop (catch_errors=3029020) at cmdloop.c:252 #34 0x17b3f8 in Fread_minibuffer_internal (prompt=3907332) at minibuf.c:188 #35 0xad5a0 in Ffuncall (nargs=1, args=0xffbed714) at eval.c:3175 #36 0x787e8 in execute_optimized_program (program=0xffbed714 "", stack_depth=1, constants_data=0x48d990) at bytecode.c:747 #37 0x7c674 in Fbyte_code (instructions=1, constants=4774272, stack_depth=5) at bytecode.c:2406 #38 0xace28 in Feval (form=4791080) at eval.c:2975 #39 0xa9338 in internal_catch (tag=3125276, func=0xac694 <Feval>, arg=4791080, threw=0x0) at eval.c:1304 #40 0x7948c in execute_rare_opcode (stack_ptr=0xffbedbdc, program_ptr=0x6e9986 "èa«\f\201J", opcode=Bcatch) at bytecode.c:1253 #41 0x78598 in execute_optimized_program (program=0xffbedbe0 "", stack_depth=141, constants_data=0x42bc10) at bytecode.c:657 #42 0x78048 in funcall_compiled_function (fun=4788368, nargs=7, args=0xffbede54) at bytecode.c:519 #43 0xad780 in Ffuncall (nargs=7, args=0xffbede34) at eval.c:3210 #44 0x787e8 in execute_optimized_program (program=0xffbede34 "", stack_depth=7, constants_data=0x46e090) at bytecode.c:747 #45 0x78048 in funcall_compiled_function (fun=4788564, nargs=7, args=0xffbee0c0) at bytecode.c:519 #46 0xad780 in Ffuncall (nargs=7, args=0xffbee0a0) at eval.c:3210 #47 0x787e8 in execute_optimized_program (program=0xffbee0a0 "", stack_depth=7, constants_data=0x48d710) at bytecode.c:747 #48 0x78048 in funcall_compiled_function (fun=4789208, nargs=1, args=0xffbee30c) at bytecode.c:519 #49 0xad780 in Ffuncall (nargs=1, args=0xffbee304) at eval.c:3210 #50 0x787e8 in execute_optimized_program (program=0xffbee304 "", stack_depth=1, constants_data=0x3fa410) at bytecode.c:747 #51 0x78048 in funcall_compiled_function (fun=4230860, nargs=1, args=0xffbee568) at bytecode.c:519 #52 0xad780 in Ffuncall (nargs=1, args=0xffbee560) at eval.c:3210 #53 0x7e7d4 in Fcall_interactively (function=4249044, record_flag=3028996, keys=3028996) at callint.c:946 #54 0xabfa8 in Fcommand_execute (cmd=4249044, record=3028996, keys=3028996) at eval.c:2613 #55 0x10045c in execute_command_event (command_builder=0x635a80, event=6861964) at event-stream.c:4333 #56 0x100da0 in Fdispatch_event (event=6861964) at event-stream.c:4644 #57 0x87718 in Fcommand_loop_1 () at cmdloop.c:575 #58 0x874ac in command_loop_1 (dummy=3028996) at cmdloop.c:490 #59 0xa9764 in condition_case_1 (handlers=2807808, bfun=0x87460 <command_loop_1>, barg=3028996, hfun=0x878f8 <cmd_error>, harg=3028996) at eval.c:1629 #60 0x87a08 in command_loop_2 (dummy=3028996) at cmdloop.c:252 #61 0xa9338 in internal_catch (tag=3111156, func=0x879bc <command_loop_2>, arg=3028996, threw=0x0) at eval.c:1304 #62 0x86de0 in initial_command_loop (load_me=555452) at cmdloop.c:301 #63 0xa540c in xemacs_21_2_b31_sparc_sun_solaris2_7 (argc=2, argv=0xffbeeed4, envp=0xffbeeee0, restart=0) at emacs.c:1879 #64 0xa5c28 in main (argc=2, argv=0xffbeeed4, envp=0xffbeeee0) at emacs.c:2305

1 participants
0 comments

Re: EUDC crash with 21.2.31 on Solaris 2.7 24 years, 10 months

Raymond Toy

>>>>> "John" == John A Turner <turner(a)blueskystudios.com> writes: >>>>> "JV" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: JV> Note that you can normally get a lisp backtrace when under gdb by JV> using 'cont' after the crash. John> as noted in a separate thread, I haven't been getting lisp backtraces John> when I crash either (Irix, gcc 2.95.2, full debug and However, in my original message, I did get a Lisp backtrace. I just haven't been able to get one in the other test cases. Ray

1 participants
0 comments

Re: EUDC crash with 21.2.31 on Solaris 2.7 24 years, 10 months

Raymond Toy

>>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> At 11:57 AM 3/15/00 -0500, Raymond Toy wrote: >> #12 0xb0524 in unbind_to_hairy (count=53) at eval.c:4615 Andy> This is the same bug Ben is seeing. Maybe you should try his workaround. You mean just removing the two offending lines the Ben marked in his message? I did that, but didn't tell anyone. temacs crashes. However, I see Gunnar Everman has a different patch, and I'm going to try that shortly.... Ray

1 participants
0 comments

Re: EUDC crash with 21.2.31 on Solaris 2.7 24 years, 10 months

Raymond Toy

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Raymond Toy <toy(a)rtp.ericsson.se> writes: Jan> 1. Add a (debug-on-entry 'eudc-set-server) to the top your options Jan> file. Single step until you get the crash (it might be you don't Jan> get it anymore) :-( >> >> Well it still crashes. :-( Jan> good... :-) >> No lisp backtrace, but here is the C backtrace. Some kind of garbage >> collection bug? Jan> Yep. Next assigment: Jan> Start XEmacs under gdb. Then set the global 'always_gc' variable to a Jan> non-zero value using gdb and repeat the procedure. It should now crash Jan> much earlier (and closer to the point where actual problem is). Ok, I did that. Except that with always_gc on, single-stepping takes forever. I just let it run until it crashed. No lisp backtrace, C backtrace appended. It looks fairly similar to my previous message, but it's a little bit shorter. Do you really want me to single-step with always_gc set? This may take a long time to debug. Ray #0 0xfec16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xfebb92a4 in abort () from /usr/lib/libc.so.1 #2 0xa6598 in assert_failed (file=0x22fad8 "alloc.c", line=2511, expr=0x230518 "GCLI_lh->type <= last_lrecord_type_index_assigned") at emacs.c:2770 #3 0x68558 in mark_object (obj=4073324) at alloc.c:2511 #4 0x6a114 in garbage_collect_1 () at alloc.c:3519 #5 0xad3d4 in Ffuncall (nargs=1, args=0xffbe9af8) at eval.c:3124 #6 0xae4c8 in run_hook_with_args_in_buffer (buf=0x2e3804, nargs=2, args=0xffbe9af8, cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3661 #7 0xae5e8 in va_run_hook_with_args (hook_var=3030364, nargs=1) at eval.c:3674 #8 0x71e8c in Frecord_buffer (buffer=3645440) at buffer.c:1416 #9 0x207c84 in Fselect_window (window=3670528, norecord=3028996) at window.c:3373 #10 0x20de1c in Fset_window_configuration (configuration=3006464) at window.c:5462 #11 0x20ea24 in save_window_excursion_unwind (window_config=3006464) at window.c:5705 #12 0xb0524 in unbind_to_hairy (count=53) at eval.c:4615 #13 0xb0468 in unbind_to (count=53, value=3028996) at eval.c:4590 #14 0xa93b0 in Fthrow (tag=3123124, val=3029020) at eval.c:1367 #15 0xad5b4 in Ffuncall (nargs=2, args=0xffbea034) at eval.c:3175 #16 0x787e8 in execute_optimized_program (program=0xffbea034 "", stack_depth=2, constants_data=0x7c3090) at bytecode.c:747 #17 0x7c674 in Fbyte_code (instructions=2, constants=8138880, stack_depth=7) at bytecode.c:2406 #18 0xace28 in Feval (form=7669348) at eval.c:2975 #19 0xa9764 in condition_case_1 (handlers=2807808, bfun=0xac694 <Feval>, barg=7669348, hfun=0xa97c8 <run_condition_case_handlers>, harg=3028996) at eval.c:1629 #20 0xa9b50 in condition_case_3 (bodyform=7669348, var=3028996, handlers=6975852) at eval.c:1707 #21 0x794e4 in execute_rare_opcode (stack_ptr=0xffbea574, program_ptr=0x6c2d54 "\207l/", opcode=Bcondition_case) at bytecode.c:1272 #22 0x78598 in execute_optimized_program (program=0xffbea57c "", stack_depth=143, constants_data=0x797490) at bytecode.c:657 #23 0x78048 in funcall_compiled_function (fun=7789444, nargs=0, args=0xffbea7c8) at bytecode.c:519 #24 0xad780 in Ffuncall (nargs=0, args=0xffbea7c4) at eval.c:3210 #25 0x787e8 in execute_optimized_program (program=0xffbea7c4 "", stack_depth=0, constants_data=0x7974b0) at bytecode.c:747 #26 0x78048 in funcall_compiled_function (fun=7789500, nargs=0, args=0xffbeaa78) at bytecode.c:519 #27 0xad780 in Ffuncall (nargs=0, args=0xffbeaa74) at eval.c:3210 #28 0xae740 in apply1 (fn=7789500, arg=3028996) at eval.c:3793 #29 0x7d0e8 in Fcall_interactively (function=7793484, record_flag=3028996, keys=3028996) at callint.c:394 #30 0xabfa8 in Fcommand_execute (cmd=7793484, record=3028996, keys=3028996) at eval.c:2613 #31 0x100420 in execute_command_event (command_builder=0x62fa80, event=7923716) at event-stream.c:4333 #32 0x100d64 in Fdispatch_event (event=7923716) at event-stream.c:4644 #33 0x87718 in Fcommand_loop_1 () at cmdloop.c:575 #34 0x874ac in command_loop_1 (dummy=3028996) at cmdloop.c:490 #35 0xa9764 in condition_case_1 (handlers=2807808, bfun=0x87460 <command_loop_1>, barg=3028996, hfun=0x878f8 <cmd_error>, harg=3028996) at eval.c:1629 #36 0x87a08 in command_loop_2 (dummy=3028996) at cmdloop.c:252 #37 0xa9338 in internal_catch (tag=3125276, func=0x879bc <command_loop_2>, arg=3028996, threw=0x0) at eval.c:1304 #38 0x8742c in Frecursive_edit () at cmdloop.c:364 #39 0xad590 in Ffuncall (nargs=0, args=0xffbeb2a4) at eval.c:3175 #40 0x787e8 in execute_optimized_program (program=0xffbeb2a4 "", stack_depth=0, constants_data=0x77c210) at bytecode.c:747 #41 0x7c674 in Fbyte_code (instructions=0, constants=7848448, stack_depth=7) at bytecode.c:2406 #42 0xace28 in Feval (form=7675564) at eval.c:2975 #43 0xa7eac in Fprogn (args=7668772) at eval.c:766 #44 0x79448 in execute_rare_opcode (stack_ptr=0xffbeb90c, program_ptr=0x7adca5 "\210\0160.&\207packages/lisp/vm/", opcode=Bsave_window_excursion) at bytecode.c:1240 #45 0x78598 in execute_optimized_program (program=0xffbeb90c "", stack_depth=139, constants_data=0x7ad010) at bytecode.c:657 #46 0x78048 in funcall_compiled_function (fun=7789416, nargs=2, args=0xffbebbac) at bytecode.c:519 #47 0xad780 in Ffuncall (nargs=2, args=0xffbebba8) at eval.c:3210 #48 0xade94 in Fapply (nargs=4, args=0xffbebc98) at eval.c:3445 #49 0xae724 in apply1 (fn=3650620, arg=7859068) at eval.c:3798 #50 0xb172c in call_debugger_259 (arg=7859068) at eval.c:336 #51 0xa9338 in internal_catch (tag=3123124, func=0xb1718 <call_debugger_259>, arg=7859068, threw=0xffbebe7c) at eval.c:1304 #52 0xa72d0 in call_debugger (arg=7859068) at eval.c:390 #53 0xad2b0 in Feval (form=8176076) at eval.c:3085 #54 0x170e00 in readevalloop (readcharfun=7627264, sourcename=7798676, evalfun=0xac694 <Feval>, printflag=0) at lread.c:1448 #55 0x16f8cc in Fload_internal (file=7798676, no_error=3028996, nomessage=3028996, nosuffix=3028996, codesys=3159004, used_codesys=3028996) at lread.c:736 #56 0xad62c in Ffuncall (nargs=-1, args=0xffbec48c) at eval.c:3175 #57 0x787e8 in execute_optimized_program (program=0xffbec48c "", stack_depth=5, constants_data=0x51de10) at bytecode.c:747 #58 0x78048 in funcall_compiled_function (fun=5374628, nargs=1, args=0xffbec704) at bytecode.c:519 #59 0xad780 in Ffuncall (nargs=1, args=0xffbec6fc) at eval.c:3210 #60 0x787e8 in execute_optimized_program (program=0xffbec6fc "", stack_depth=1, constants_data=0x7c3190) at bytecode.c:747 #61 0x7c674 in Fbyte_code (instructions=1, constants=8139136, stack_depth=5) at bytecode.c:2406 #62 0xace28 in Feval (form=7800072) at eval.c:2975 #63 0x170e00 in readevalloop (readcharfun=7390208, sourcename=5814628, evalfun=0xac694 <Feval>, printflag=0) at lread.c:1448 #64 0x16f8cc in Fload_internal (file=5814628, no_error=3028996, nomessage=3029020, nosuffix=3028996, codesys=3154500, used_codesys=3028996) at lread.c:736 #65 0xad62c in Ffuncall (nargs=-1, args=0xffbece94) at eval.c:3175 #66 0x787e8 in execute_optimized_program (program=0xffbece94 "", stack_depth=5, constants_data=0x51de10) at bytecode.c:747 #67 0x78048 in funcall_compiled_function (fun=5374628, nargs=4, args=0xffbed114) at bytecode.c:519 #68 0xad780 in Ffuncall (nargs=4, args=0xffbed100) at eval.c:3210 #69 0xae8c0 in call4 (fn=3170308, arg0=5814628, arg1=3028996, arg2=3029020, arg3=3028996) at eval.c:3876 #70 0x12c830 in Frequire (feature=6214236, file_name=3028996) at fns.c:3304 #71 0xad5b4 in Ffuncall (nargs=-1, args=0xffbed2bc) at eval.c:3175 #72 0x787e8 in execute_optimized_program (program=0xffbed2bc "", stack_depth=1, constants_data=0x6f0e10) at bytecode.c:747 #73 0x7c674 in Fbyte_code (instructions=1, constants=7278080, stack_depth=5) at bytecode.c:2406 #74 0xace28 in Feval (form=4017932) at eval.c:2975 #75 0x170e00 in readevalloop (readcharfun=7390720, sourcename=6370580, evalfun=0xac694 <Feval>, printflag=0) at lread.c:1448 #76 0x16f8cc in Fload_internal (file=6370580, no_error=3028996, nomessage=3028996, nosuffix=3028996, codesys=3154500, used_codesys=3028996) at lread.c:736 #77 0xad62c in Ffuncall (nargs=-1, args=0xffbeda14) at eval.c:3175 #78 0x787e8 in execute_optimized_program (program=0xffbeda14 "", stack_depth=5, constants_data=0x51de10) at bytecode.c:747 #79 0x78048 in funcall_compiled_function (fun=5374628, nargs=1, args=0xffbedc8c) at bytecode.c:519 #80 0xad780 in Ffuncall (nargs=1, args=0xffbedc84) at eval.c:3210 #81 0x787e8 in execute_optimized_program (program=0xffbedc84 "", stack_depth=1, constants_data=0x4864d0) at bytecode.c:747 #82 0x78048 in funcall_compiled_function (fun=5041000, nargs=1, args=0xffbedf50) at bytecode.c:519 #83 0xad780 in Ffuncall (nargs=1, args=0xffbedf48) at eval.c:3210 #84 0xadcf8 in Fapply (nargs=2, args=0xffbedf48) at eval.c:3388 #85 0xae724 in apply1 (fn=5041000, arg=3989320) at eval.c:3798 #86 0x7d0e8 in Fcall_interactively (function=5051116, record_flag=3029020, keys=3028996) at callint.c:394 #87 0xabfa8 in Fcommand_execute (cmd=5051116, record=3029020, keys=3028996) at eval.c:2613 #88 0xad5cc in Ffuncall (nargs=-1, args=0xffbee304) at eval.c:3175 #89 0x787e8 in execute_optimized_program (program=0xffbee304 "", stack_depth=2, constants_data=0x3fa410) at bytecode.c:747 #90 0x78048 in funcall_compiled_function (fun=4230860, nargs=1, args=0xffbee568) at bytecode.c:519 #91 0xad780 in Ffuncall (nargs=1, args=0xffbee560) at eval.c:3210 #92 0x7e7d4 in Fcall_interactively (function=4249044, record_flag=3028996, keys=3028996) at callint.c:946 #93 0xabfa8 in Fcommand_execute (cmd=4249044, record=3028996, keys=3028996) at eval.c:2613 #94 0x100420 in execute_command_event (command_builder=0x62fa80, event=6739200) at event-stream.c:4333 #95 0x100d64 in Fdispatch_event (event=6739200) at event-stream.c:4644 #96 0x87718 in Fcommand_loop_1 () at cmdloop.c:575 #97 0x874ac in command_loop_1 (dummy=3028996) at cmdloop.c:490 #98 0xa9764 in condition_case_1 (handlers=2807808, bfun=0x87460 <command_loop_1>, barg=3028996, hfun=0x878f8 <cmd_error>, harg=3028996) at eval.c:1629 #99 0x87a08 in command_loop_2 (dummy=3028996) at cmdloop.c:252 #100 0xa9338 in internal_catch (tag=3111156, func=0x879bc <command_loop_2>, arg=3028996, threw=0x0) at eval.c:1304 #101 0x86de0 in initial_command_loop (load_me=555452) at cmdloop.c:301 #102 0xa540c in xemacs_21_2_b31_sparc_sun_solaris2_7 (argc=2, argv=0xffbeeecc, envp=0xffbeeed8, restart=0) at emacs.c:1879 #103 0xa5c28 in main (argc=2, argv=0xffbeeecc, envp=0xffbeeed8) at emacs.c:2305

2 participants
1 comments

Re: nasty crash 24 years, 10 months

Gunnar Evermann

Martin Buchholz <martin(a)xemacs.org> writes: > >>>>> "GE" == Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > GE> Martin, I'd suggest to move the increments into the macros to make > GE> this more obvious. > > But that would make the macro a nanosecond slower by making it expand > to larger code. We could of course add a comment for clarity instead. I knew you would say that. :-) > Maybe it has to do with the #if 0 I wrapped around the following code > in unbind_to_hairy(). My assumption was that if this broke, we would > find out rather quickly - and it's been more than a year now... Yes that's my best guess at the moment as well, especially since Raymond's backtraces seem to indicate that one element in the catchlist is corrupted and involve Fthrow (and just about every other non-trivial function in XEmacs). Maybe we (and especially Raymond) can try running with the following (untested) patch. Any backtraces might give new hints. --- eval.c Wed Mar 15 20:55:26 2000 +++ eval.c-check Wed Mar 15 21:47:02 2000 ＠＠ -4667,7 +4667,6 ＠＠ Fset (specpdl_ptr->symbol, specpdl_ptr->old_value); } -#if 0 /* martin */ #ifndef EXCEEDINGLY_QUESTIONABLE_CODE /* There should never be anything here for us to remove. If so, it indicates a logic error in Emacs. Catches ＠＠ -4682,9 +4681,9 ＠＠ while (catchlist && catchlist->pdlcount > specpdl_depth_counter) { + assert(0); catchlist = catchlist->next; /* Don't mess with gcprolist, backtrace_list here */ } -#endif #endif } if (quitf)

1 participants
0 comments

Am working on the debianization again... 24 years, 10 months

Karl M. Hegbloom

I plan to take this as far as getting it to build XEmacs so I can run it from ${builddir} for a while, then get back to work on `boot-floppies'. When `Potato' is released, I'll finish up and get it to create Debian packages of XEmacs-21.2-beta, dividing my time between it, the `install-system' build setup, and the reading I really ought to be doing instead. I will not release to the general public until both it works, and yous release also. When it's ready, I will attempt to either wrangle control of the XEmacs packages from James LewisMoss, or form a maintainer team. I think the maintainer team is the best route, since I do not know any non-english languages and will need help getting the -mule packages right. Thought you might want to take a look at my pile of makefile spaghetti. It is still only "half" thought out at this point... that will be very obvious when you look at it. Sorry about the mule jokes... I was in a flippant mood late one long night. There is a lot of cruft that will go away before the mule does the standard stage stamp and the fat lady sings. What I do to make this work is run a checkout of xemacs and xemacs-packages from cvs.xemacs.org, and then run a checkout of the xemacs/debian and xemacs-packages/debian modules from my own repository. It doesn't work yet, but hopefully by the end of today or tomorrow, I can run from ${srcdir} and a symlink tree of the xemacs-packages. <URL:http://bittersweet.inetarena.com/cgi-bin/cvsweb> CVSROOT=:pserver:anoncvs＠bittersweet.inetarena.com:/var/cvs/debian cvs login (empty password) cvs checkout xemacs/debian xemacs-packages/debian

1 participants
0 comments

Re: EUDC crash with 21.2.31 on Solaris 2.7 24 years, 10 months

Jan Vroonhof

Raymond Toy <toy(a)rtp.ericsson.se> writes: > Jan> Could you give us a trace without the debugger then? (but with > Jan> always_gc). > > I tried this using gdb attach. It takes a long time, but I get no > lisp backtrace. Can you post the C backtrace from that case? (Although it also shouldn't crash in the debugger). Jan

2 participants
1 comments

Re: nasty crash 24 years, 10 months

Gunnar Evermann

[ removed some CCs -- why was this on -review anyway? ] Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Ben Wing <ben(a)666.com> writes: > > > Looking at unbind_to_hairy(), I think I see a logic error. If so, it's > > amazing we are able to run ok at all. > > There are other people seeing very weird crashes involving very deep > traces (see for instance the eudc thread). > > P.S. Most of these crashes involve deep levels of bytecode execution. > I am wondering whether this (or a related) change triggered it. > > 1999-01-30 Martin Buchholz <martin(a)xemacs.org> > > * bytecode.c (funcall_compiled_function): Call > UNBIND_TO_GCPRO instead of UNBIND_TO_GCPRO_VARIABLES_ONLY. No, this patch should be really save. It only undid one of Martin's optimisations :-) Maybe I am misreading the code but I think the ++specpdl_ stuff in unbind_to_hairy() is necessary because it is called from the UNBIND_TO* macros. my interpretation of the code is: - the UNBIND_TO* macros handle the normal variable case. - unbind_to_hairy() is basically the old (pre-marzilla patch) unbind_to() - in UNBIND_TO* we first decrement the specpdl counters and then only if we are not dealing with a normal variable call unbind_to_hairy(). The first thing unbind_to_hairy() has to do is to undo the decrement done in the macro. Martin, I'd suggest to move the increments into the macros to make this more obvious. Ben, am I missing something here? What did you mean by 'logic error'? Gunnar

2 participants
1 comments

2025

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