March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

William M. Perry

I've got the ldap and gpm code in the latest CVS snapshot usable. Do we want to make this a default for 21.2? Are there any other pieces that should be moved into modules as a proof-of-concept? For LDAP and GPM it was basically cp ../modules/xxx and a makefile tweek. Other than that it worked out of the box. Someone mentioned a while ago that the portable dumper screwed up modules... not quite sure I see why. In theory you shouldn't be dumping out any of those objects, but... -Bill P.

1 participants
0 comments

PC / Internet fax solution 24 years, 8 months

port22＠rnhnet.com

I stopped by your web site and thought you may be interested in our PC/internet based fax service. You can send 1 to 1,000,000 faxes in just minutes to any destination in the US, Canada, and Europe for as low as 7.4 cents per minute. Our user-friendly submission software lets you queue your job on our server within minutes. Why not try the system for FREE. We will be happy to send 100 Faxes on your behalf to your fax list immediately. Simply go to http://www.efaxcast.com/submit.htm

1 participants
0 comments

Re: Eureka! 24 years, 8 months

William M. Perry

Martin Buchholz <martin(a)xemacs.org> writes: > >>>>> "Ben" == Ben Wing <ben(a)666.com> writes: > Thanks, Ben. > > Ben> This looks to be a fix for all crashes involving > Ben> condition_case_unwind(), and the finger gets pointed at Martin, who was > Ben> the one rearranging this code in an attempt to squeeze out microseconds. > ^^^^^ > nano Femto? :) -bp

1 participants
0 comments

Eureka! 24 years, 8 months

Ben Wing

This looks to be a fix for all crashes involving condition_case_unwind(), and the finger gets pointed at Martin, who was the one rearranging this code in an attempt to squeeze out microseconds. Index: eval.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/eval.c,v retrieving revision 1.27.2.21 diff -u -r1.27.2.21 eval.c --- eval.c 2000/03/13 07:27:53 1.27.2.21 +++ eval.c 2000/03/16 12:34:21 ＠＠ -4641,13 +4660,13 ＠＠ { int quitf; + ++specpdl_ptr; + ++specpdl_depth_counter; + check_quit (); /* make Vquit_flag accurate */ quitf = !NILP (Vquit_flag); Vquit_flag = Qnil; - ++specpdl_ptr; - ++specpdl_depth_counter; - while (specpdl_depth_counter != count) { --specpdl_ptr; -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.

2 participants
1 comments

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

Raymond Toy

>>>>> "Raymond" == Raymond Toy <toy(a)rtp.ericsson.se> writes: >>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> "John A. Turner" <turner(a)blueskystudios.com> writes: >>> oh, I didn't realize I should be doing that as well - I thought I was >>> seeing a different crash from the one in this thread Jan> Oops, sorry. I meant I wanted Raymond to do that... Although Andy Jan> thinks it might a garbage collect thing, in that case setting Jan> always_gc should make it easier to reproduce. Raymond> I've been doing that for the last several hours. I started xemacs Raymond> -vanilla, did M-x load-lib RET, had gdb attach to the process and set Raymond> always_gc to 1, and detached. Then I answered the prompt. Ok, I must have screwed something up. I redid this except I waited until eudc prompted me to configure the search base. I set always_gc at this point and continued. The Lisp and C stack traces are appended below. I see that it's not crashing in GC anymore. Note that this includes Ben's latest patch to fix the unbind_to_hairy stuff. Ray Lisp stack trace: # bind (no-save protocol server) eudc-set-server("mbb1.ericsson.se" ldap t) # bind (current-load-list) # (unwind-protect ...) # bind (load-file-name) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load-internal("~/.eudc-options" nil nil nil undecided) # bind (path handler filename nosuffix nomessage noerror file) load("~/.eudc-options") byte-code("..." [noninteractive locate-library eudc-options-file message "" featurep load infodock eudc-install-menu] 2) # bind (current-load-list) # (unwind-protect ...) # bind (load-file-name) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load-internal("eudc" nil t nil binary) # bind (path handler filename nosuffix nomessage noerror file) load("eudc" nil t nil) # (unwind-protect ...) require(eudc) byte-code("..." [require eudc bbdb bbdb-com] 2) # bind (current-load-list) # (unwind-protect ...) # bind (load-file-name) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) # (unwind-protect ...) load-internal("eudc-export" nil nil nil binary) # bind (path handler filename nosuffix nomessage noerror file) load("eudc-export") # bind (library) #<compiled-function (library) "...(4)" [load library] 2 872567 (list (read-library "Load library: " load-path nil nil nil ...))>("eudc-export") call-interactively(load-library) command-execute(load-library t) # bind (_execute_command_keys_ _execute_command_name_ prefix-arg) execute-extended-command(nil) # bind (command-debug-status) call-interactively(execute-extended-command) # (condition-case ... . error) # (catch top-level ...) C stack trace: #0 0xfec16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xa3870 in fatal_error_signal (sig=6) at emacs.c:272 #2 <signal handler called> #3 0xfec16870 in _libc_kill () from /usr/lib/libc.so.1 #4 0xfebb92a4 in abort () from /usr/lib/libc.so.1 #5 0xa6598 in assert_failed (file=0x2330d0 "lisp.h", line=1087, expr=0x233180 "RECORD_TYPEP (obj, lrecord_type_symbol)") at emacs.c:2770 #6 0x785f8 in execute_optimized_program (program=0xffbebd50 "", stack_depth=17, constants_data=0x75d590) at lisp.h:1087 #7 0x78048 in funcall_compiled_function (fun=7622236, nargs=3, args=0xffbebf04) at bytecode.c:519 #8 0xad0d8 in Feval (form=7850552) at eval.c:3034 #9 0x170df8 in readevalloop (readcharfun=7627264, sourcename=7797348, evalfun=0xac694 <Feval>, printflag=0) at lread.c:1448 #10 0x16f8c4 in Fload_internal (file=7797348, no_error=3028996, nomessage=3028996, nosuffix=3028996, codesys=3159004, used_codesys=3028996) at lread.c:736 #11 0xad62c in Ffuncall (nargs=-1, args=0xffbec48c) at eval.c:3175 #12 0x787e8 in execute_optimized_program (program=0xffbec48c "", stack_depth=5, constants_data=0x51de10) at bytecode.c:747 #13 0x78048 in funcall_compiled_function (fun=5374628, nargs=1, args=0xffbec704) at bytecode.c:519 #14 0xad780 in Ffuncall (nargs=1, args=0xffbec6fc) at eval.c:3210 #15 0x787e8 in execute_optimized_program (program=0xffbec6fc "", stack_depth=1, constants_data=0x769210) at bytecode.c:747 #16 0x7c674 in Fbyte_code (instructions=1, constants=7770624, stack_depth=5) at bytecode.c:2406 #17 0xace28 in Feval (form=7800612) at eval.c:2975 #18 0x170df8 in readevalloop (readcharfun=7390208, sourcename=5801524, evalfun=0xac694 <Feval>, printflag=0) at lread.c:1448 #19 0x16f8c4 in Fload_internal (file=5801524, no_error=3028996, nomessage=3029020, nosuffix=3028996, codesys=3154500, used_codesys=3028996) at lread.c:736 #20 0xad62c in Ffuncall (nargs=-1, args=0xffbece94) at eval.c:3175 #21 0x787e8 in execute_optimized_program (program=0xffbece94 "", stack_depth=5, constants_data=0x51de10) at bytecode.c:747 #22 0x78048 in funcall_compiled_function (fun=5374628, nargs=4, args=0xffbed114) at bytecode.c:519 #23 0xad780 in Ffuncall (nargs=4, args=0xffbed100) at eval.c:3210 #24 0xae8c0 in call4 (fn=3170308, arg0=5801524, arg1=3028996, arg2=3029020, arg3=3028996) at eval.c:3876 #25 0x12c828 in Frequire (feature=6218332, file_name=3028996) at fns.c:3304 #26 0xad5b4 in Ffuncall (nargs=-1, args=0xffbed2bc) at eval.c:3175 #27 0x787e8 in execute_optimized_program (program=0xffbed2bc "", stack_depth=1, constants_data=0x6f0e70) at bytecode.c:747 #28 0x7c674 in Fbyte_code (instructions=1, constants=7278176, stack_depth=5) at bytecode.c:2406 #29 0xace28 in Feval (form=4051548) at eval.c:2975 #30 0x170df8 in readevalloop (readcharfun=7390720, sourcename=3699572, evalfun=0xac694 <Feval>, printflag=0) at lread.c:1448 #31 0x16f8c4 in Fload_internal (file=3699572, no_error=3028996, nomessage=3028996, nosuffix=3028996, codesys=3154500, used_codesys=3028996) at lread.c:736 #32 0xad62c in Ffuncall (nargs=-1, args=0xffbeda14) at eval.c:3175 #33 0x787e8 in execute_optimized_program (program=0xffbeda14 "", stack_depth=5, constants_data=0x51de10) at bytecode.c:747 #34 0x78048 in funcall_compiled_function (fun=5374628, nargs=1, args=0xffbedc8c) at bytecode.c:519 #35 0xad780 in Ffuncall (nargs=1, args=0xffbedc84) at eval.c:3210 #36 0x787e8 in execute_optimized_program (program=0xffbedc84 "", stack_depth=1, constants_data=0x4864d0) at bytecode.c:747 #37 0x78048 in funcall_compiled_function (fun=5041000, nargs=1, args=0xffbedf50) at bytecode.c:519 #38 0xad780 in Ffuncall (nargs=1, args=0xffbedf48) at eval.c:3210 #39 0xadcf8 in Fapply (nargs=2, args=0xffbedf48) at eval.c:3388 #40 0xae724 in apply1 (fn=5041000, arg=6135516) at eval.c:3798 #41 0x7d0e8 in Fcall_interactively (function=5051116, record_flag=3029020, keys=3028996) at callint.c:394 #42 0xabfa8 in Fcommand_execute (cmd=5051116, record=3029020, keys=3028996) at eval.c:2613 #43 0xad5cc in Ffuncall (nargs=-1, args=0xffbee304) at eval.c:3175 #44 0x787e8 in execute_optimized_program (program=0xffbee304 "", stack_depth=2, constants_data=0x3fa410) at bytecode.c:747 #45 0x78048 in funcall_compiled_function (fun=4230860, nargs=1, args=0xffbee568) at bytecode.c:519 #46 0xad780 in Ffuncall (nargs=1, args=0xffbee560) at eval.c:3210 #47 0x7e7d4 in Fcall_interactively (function=4249044, record_flag=3028996, keys=3028996) at callint.c:946 #48 0xabfa8 in Fcommand_execute (cmd=4249044, record=3028996, keys=3028996) at eval.c:2613 #49 0x100418 in execute_command_event (command_builder=0x635a80, event=6862080) at event-stream.c:4333 #50 0x100d5c in Fdispatch_event (event=6862080) at event-stream.c:4644 #51 0x87718 in Fcommand_loop_1 () at cmdloop.c:575 #52 0x874ac in command_loop_1 (dummy=3028996) at cmdloop.c:490 #53 0xa9764 in condition_case_1 (handlers=2807808, bfun=0x87460 <command_loop_1>, barg=3028996, hfun=0x878f8 <cmd_error>, harg=3028996) at eval.c:1629 #54 0x87a08 in command_loop_2 (dummy=3028996) at cmdloop.c:252 #55 0xa9338 in internal_catch (tag=3111156, func=0x879bc <command_loop_2>, arg=3028996, threw=0x0) at eval.c:1304 #56 0x86de0 in initial_command_loop (load_me=555452) at cmdloop.c:301 #57 0xa540c in xemacs_21_2_b31_sparc_sun_solaris2_7 (argc=2, argv=0xffbeeed4, envp=0xffbeeee0, restart=0) at emacs.c:1879 #58 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, 8 months

Raymond Toy

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> "John A. Turner" <turner(a)blueskystudios.com> writes: >> oh, I didn't realize I should be doing that as well - I thought I was >> seeing a different crash from the one in this thread Jan> Oops, sorry. I meant I wanted Raymond to do that... Although Andy Jan> thinks it might a garbage collect thing, in that case setting Jan> always_gc should make it easier to reproduce. I've been doing that for the last several hours. I started xemacs -vanilla, did M-x load-lib RET, had gdb attach to the process and set always_gc to 1, and detached. Then I answered the prompt. It was using 100% CPU for a while, but now it uses 0% CPU unless it has focus. I can't leave my mouse there all day because I need to do real work too! :-) Actually it has something to do with fvwm screens. When I switch to a different screen xemacs stops using CPU. When I move the mouse back to xemacs, it starts using CPU again. As long as I stay in that screen, xemacs uses CPU. Weird. This also brings up something I've noticed but haven't narrowed done. Sometimes, especially with eudc, the focus is moved to someplace weird even though the mouse is over the xemacs window. Moving the mouse out and back in fixes this, but it's annoying. Slowly waiting for that always_gc crash.... Ray

1 participants
0 comments

Refresh bug with the process gauge 24 years, 8 months

Olivier Galibert

cvs of now. In my .emacs: (setq-default font-lock-auto-fontify t) (require 'font-lock) I did: - open a new frame with gnuclient FlowAudio.h - C-x C-f FlowAudio.cc - C-x 5 2 - (in the new frame, the right one) C-x C-f Flow.h The font-lock gauge appeared normally in the right frame but then went to the laft one and stayed here a while (but eventually dissapeared). May even be reproducible (happened again when I opened my .emacs in the right frame). OG. ObSnapshot:

1 participants
0 comments

Crash 21.2.31 on Solaris 5.6 24 years, 8 months

Ulrich Kaage

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta31) "Iris" [Lucid] (sparc-sun-solaris2.6, Mule) of Tue Mar 14 2000 on inss24 configured using `configure --prefix=/usr/users/kaage/lib/xemacs --dynamic=yes --with-dialogs=athena --with-site-lisp --with-mule' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I tried activating the menu-accelerators via "Options->Menubars->Alt/Meta Selects Menu Items". This action resultet in a Fatal error (11). However, I could not reproduce this bug. Lisp backtrace follows: # (condition-case ... . error) # (catch top-level ...) GDB backtrace follows: (gdb) where #0 0xef10800c in _libc_kill () from /lib/libc.so.1 #1 0xa398c in fatal_error_signal (sig=11) at emacs.c:272 #2 <signal handler called> #3 0xef3a5f60 in _XtWindowedAncestor () from /lib/libXt.so.4 #4 0xef3a156c in XtConfigureWidget () from /lib/libXt.so.4 #5 0x1fbd48 in x_map_subwindow (p=0xf3fc80, x=4, y=720, dga=0xefffe5e0) at glyphs-x.c:2153 #6 0x14778c in map_subwindow (subwindow=4, x=4, y=41, dga=0xefffe5e0) at glyphs.c:4431 #7 0x1ad258 in redisplay_output_subwindow (w=0xc84800, image_instance=15989888, db=0xefffe698, dga=0xefffe688, findex=9, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-output.c:1216 #8 0x202b1c in x_output_display_block (w=0xc84800, dl=0xe11400, block=0, start=9, end=1, start_pixpos=4, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-x.c:482 #9 0x1acfdc in redisplay_output_display_block (w=0xc84800, dl=0xe11400, block=0, start=9, end=1, start_pixpos=4, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-output.c:1099 #10 0x1ab220 in compare_display_blocks (w=0xc84800, cdl=0xeda800, ddl=0xe11400, c_block=1, d_block=0, start_pixpos=4, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-output.c:479 #11 0x1abf64 in output_display_line (w=0xc84800, cdla=0xbfa0c0, ddla=0xdfe1c0, line=0, force_start=4, force_end=724) at redisplay-output.c:729 #12 0x15b4b4 in output_gutter (f=0x0, pos=TOP_GUTTER, force=0) at gutter.c:314 #13 0x15cb90 in update_frame_gutters (f=0xd82400) at gutter.c:524 #14 0x1a0d78 in redisplay_frame (f=0xd82400, preemption_check=0) at redisplay.c:6406 #15 0x1a1014 in redisplay_device (d=0x634200, automatic=14164992) at redisplay.c:6493 #16 0x1a1594 in redisplay_without_hooks () at redisplay.c:6582 #17 0x1a1814 in redisplay () at redisplay.c:6639 #18 0xfc75c in Fnext_event (event=13487360, prompt=3123204) at event-stream.c:2173 #19 0x881d8 in Fcommand_loop_1 () at cmdloop.c:566 #20 0x87f28 in command_loop_1 (dummy=3123204) at cmdloop.c:490 #21 0xa9cfc in condition_case_1 (handlers=3123300, bfun=0x87edc <command_loop_1>, barg=3123204, hfun=0x8738c <cmd_error>, harg=3123204) at eval.c:1644 #22 0x874a0 in command_loop_3 () at cmdloop.c:252 #23 0x874c0 in command_loop_2 (dummy=3123204) at cmdloop.c:263 #24 0xa97e4 in internal_catch (tag=3205364, func=0x874b4 <command_loop_2>, arg=3123204, threw=0x0) at eval.c:1310 #25 0x87824 in initial_command_loop (load_me=554164) at cmdloop.c:301 #26 0xa4fb4 in sort_args (argc=2932736, argv=0xeffff164) at emacs.c:1828 -- Dipl.-Ing. U.Kaage Tel. ++49/(0)721/608-6273 Institut fuer Nachrichtentechnik Fax. ++49/(0)721/608-6071 Universitaet Karlsruhe (TH) kaage(a)int.uni-karlsruhe.de 76128 Karlsruhe Home Page und PGP-Key: http://www-int.etec.uni-karlsruhe.de/~kaage/

2 participants
1 comments

throw recursion 24 years, 8 months

Andy Piper

I can reproduce this reliably. xemacs -q find file on gutter-items.el edebug-defun on update-tab-in-gutter C-x 5 2 *boom* andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Re: 24 years, 8 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > It would be really nice to have clash detection back. I remember > somebody (you?) mentioning an algorithm how clash detection could be > implemented to work reliably. > Whatever happened to that project? Its in 21.2 since January 1999 or so (I implemented it in September 1998, just after the feature freeze). It just needs to be enabled again. Jan P.S. It is the algorithm from FSF 20.2. I intentionally did not implement the boot-id stuff from later FSF versions. As far as I know that still doesn't work well enough to be worth the trouble.

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