August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Seppuku and x_IO_error_handler() 26 years, 3 months

Hrvoje Niksic

(resent from xemacs-patches) Try this with your XEmacs: * start a console XEmacs using `xemacs -nw'; * create an X frame using `M-x make-frame-on-display RET DISPLAY RET'; * close the X frame using the X "kill" facility. For me, XEmacs exits without printing anything, instead of just shutting down the X frame. This is, of course, a manifestation of the infamous "XEmacs-dies-along-with-the-X-server" syndrome. Fiddling with `x-seppuku-on-epipe', the only related variable, makes XEmacs exit even sooner, all without proper autosaving. In fact, setting `x-seppuku-on-epipe' is "required" on some systems because not using it confuses the hell out of Xlib. Problem summary: when XEmacs loses connection to the X server, x_IO_error_handler() is called. The function enqueues an event to wipe out the offending console at an appropriate time, and returns. The "returns" part is wrong, because it either confuses Xlib, or makes it exit right away or when the next X event is processed. The right solution is for x_IO_error_handler to throw to top level without ever returning to Xlib. However, this leaves the (very real) possibility of bogus X events sitting in the Xt event queue and crashing XEmacs at the first opportunity. Because of this, x_IO_error_handler() needs to set a device->being_deleted flag, and the functions in event-Xt.c that handle raw X events need to check the flag and ignore the events coming from devices on which it is set. This obviates the need for `x-seppuku-on-epipe'. This wisdom is the result of a two-day investigation followed by an email/voice discussion with Ben. Eventually I've written the patch below, to be applied to 21.1 (the patch is applicable to 21.0, but this is far from "critical bugfix"). I would like gnuclient users to apply the patch and let me know if it fixes the XEmacs-dies-along-with-the-X-server problem. 1998-08-28 Hrvoje Niksic <hniksic(a)srce.hr> * event-Xt.c (emacs_Xt_mapping_action): Check for device being deleted. (x_event_to_emacs_event): Ditto. (emacs_Xt_handle_focus_event): Ditto. (emacs_Xt_handle_magic_event): Ditto. * console-x.h (struct x_device): New flag being_deleted. (DEVICE_X_BEING_DELETED): New macro. * device-x.c (x_IO_error_handler): Throw to top-level instead of returning. Before doing that, set the being_deleted flag on the device. 1998-08-27 Hrvoje Niksic <hniksic(a)srce.hr> * device-x.c (x-seppuku-on-epipe): Removed. --- src/device-x.c.orig Wed Aug 26 20:27:44 1998 +++ src/device-x.c Fri Aug 28 04:23:56 1998 ＠＠ -62,9 +62,6 ＠＠ Lisp_Object Qx_error; Lisp_Object Qinit_pre_x_win, Qinit_post_x_win; -/* $B＠ZJ"(B, n. Japanese ritual suicide. */ -int x_seppuku_on_epipe; - /* The application class of Emacs. */ Lisp_Object Vx_emacs_application_class; ＠＠ -880,10 +877,8 ＠＠ Lisp_Object dev; struct device *d = get_device_from_display_1 (disp); - if (d) - XSETDEVICE (dev, d); - else - dev = Qnil; + assert (d != NULL); + XSETDEVICE (dev, d); if (NILP (find_nonminibuffer_frame_not_on_device (dev))) { ＠＠ -903,31 +898,24 ＠＠ { warn_when_safe (Qx, Qcritical, - "I/O Error %d (%s) on display connection \"%s\"\n" - " after %lu requests (%lu known processed) with " - "%d events remaining.\n", + "I/O Error %d (%s) on display connection\n" + " \"%s\" after after %lu requests (%lu known processed)\n" + " with %d events remaining.\n" + " Throwing to top level.\n", errno, strerror (errno), DisplayString (disp), NextRequest (disp) - 1, LastKnownRequestProcessed (disp), QLength (disp)); } + /* According to X specs, we should not return from this function, or + Xlib might just decide to exit(). So we mark the offending + console for deletion and throw to top level. */ if (d) enqueue_magic_eval_event (io_error_delete_device, dev); + DEVICE_X_BEING_DELETED (d) = 1; + Fthrow (Qtop_level, Qnil); - /* CvE, July 16, 1996, XEmacs 19.14 */ - /* Test for broken pipe error, which indicates X-server has gone down */ - if (errno == EPIPE && x_seppuku_on_epipe) - { - /* Most probably X-server has gone down: Avoid infinite loop by just */ - /* exiting */ - /* slb: This sounds really, really dangerous to do by default, so */ - /* I'm adding a guard to avoid doing this as default behavior */ - stderr_out( "\n\nXEmacs exiting on broken pipe (errno %d, %s)\n", - errno, strerror(errno)); - exit(errno); - } - - return 0; + RETURN_NOT_REACHED (0); } DEFUN ("x-debug-mode", Fx_debug_mode, 1, 2, 0, /* ＠＠ -1733,14 +1721,6 ＠＠ just reside in C. */ ); Vx_initial_argv_list = Qnil; - - DEFVAR_BOOL ("x-seppuku-on-epipe", &x_seppuku_on_epipe /* -When non-nil, terminate XEmacs immediately on SIGPIPE from the X server. -XEmacs doesn't terminate properly on some systems. -When this variable is non-nil, XEmacs will commit immediate suicide -when it gets a sigpipe from the X Server. -*/ ); - x_seppuku_on_epipe = 0; #if defined(MULE) && (defined(LWLIB_MENUBARS_MOTIF) || defined(HAVE_XIM) || defined (USE_XFONTSET)) DEFVAR_LISP ("x-app-defaults-directory", &Vx_app_defaults_directory /* --- src/device.c.orig Fri Aug 28 03:42:11 1998 +++ src/device.c Fri Aug 28 03:42:12 1998 ＠＠ -817,6 +817,9 ＠＠ void io_error_delete_device (Lisp_Object device) { + /* Note: it's the console that should get deleted, but + delete_device_internal() contains a hack that also deletes the + console when called from this function. */ delete_device_internal (XDEVICE (device), 1, 0, 1); } --- src/console-x.h.orig Fri Aug 28 03:44:44 1998 +++ src/console-x.h Fri Aug 28 03:49:21 1998 ＠＠ -70,6 +70,9 ＠＠ /* The X connection of this device. */ Display *display; + /* Set by x_IO_error_handler(). */ + int being_deleted; + /* Xt application info. */ Widget Xt_app_shell; ＠＠ -184,6 +187,7 ＠＠ #define FRAME_X_DISPLAY(f) (DEVICE_X_DISPLAY (XDEVICE (f->device))) #define DEVICE_X_DISPLAY(d) (DEVICE_X_DATA (d)->display) +#define DEVICE_X_BEING_DELETED(d) (DEVICE_X_DATA (d)->being_deleted) #define DEVICE_X_VISUAL(d) (DEVICE_X_DATA (d)->visual) #define DEVICE_X_DEPTH(d) (DEVICE_X_DATA (d)->depth) #define DEVICE_X_COLORMAP(d) (DEVICE_X_DATA (d)->device_cmap) --- src/event-Xt.c.orig Fri Aug 28 03:53:15 1998 +++ src/event-Xt.c Fri Aug 28 03:56:52 1998 ＠＠ -658,6 +658,9 ＠＠ emacs_Xt_mapping_action (Widget w, XEvent* event) { struct device *d = get_device_from_display (event->xany.display); + + if (DEVICE_X_BEING_DELETED (d)) + return; #if 0 /* nyet. Now this is handled by Xt. */ XRefreshKeyboardMapping (&event->xmapping); ＠＠ -923,6 +926,10 ＠＠ struct device *d = get_device_from_display (display); struct x_device *xd = DEVICE_X_DATA (d); + if (DEVICE_X_BEING_DELETED (d)) + /* #### Uh, is this 0 correct? */ + return 0; + set_last_server_timestamp (d, x_event); switch (x_event->type) ＠＠ -1335,14 +1342,17 ＠＠ void emacs_Xt_handle_focus_event (XEvent *event) { + struct device *d = get_device_from_display (event->xany.display); + struct frame *f; + + if (DEVICE_X_BEING_DELETED (d)) + return; + /* * It's curious that we're using x_any_window_to_frame() instead * of x_window_to_frame(). I don't know what the impact of this is. */ - - struct frame *f = - x_any_window_to_frame (get_device_from_display (event->xany.display), - event->xfocus.window); + f = x_any_window_to_frame (d, event->xfocus.window); if (!f) /* focus events are sometimes generated just before a frame is destroyed. */ ＠＠ -1509,7 +1519,7 ＠＠ XEvent *event = &emacs_event->event.magic.underlying_x_event; struct frame *f = XFRAME (EVENT_CHANNEL (emacs_event)); - if (!FRAME_LIVE_P (f)) + if (!FRAME_LIVE_P (f) || DEVICE_X_BEING_DELETED (XDEVICE (FRAME_DEVICE (f)))) return; switch (event->type) -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Silence!" cries Freydag. "I did not call thee in for a consultation!" "They are my innards! I will not have them misread by a poseur!"

1 participants
0 comments

(cdr (cdr (car ls))) vs (cddar ls) 26 years, 3 months

Karl M. Hegbloom

In pcl-cvs.el:1604 ((eq (car (car parse-spec)) 'COLLECT) (setq *result* (cons (eval (car (cdr (car parse-spec)))) *result*))) ((eq (car (car parse-spec)) 'PROG) (eval (car (cdr (car parse-spec))))) ((eq (car (car parse-spec)) 'REGEXP) (cond ;; Is it a match? (The regexp must be anchored at the end of a line). ((and (looking-at (car (cdr (car parse-spec)))) (progn (goto-char (match-end 0)) (eolp))) [...] Is there any reason I should *not* change things like this to read: ((eq (caar parse-spec) 'COLLECT) (setq *result* (cons (eval (cadar parse-spec)) *result*))) ((eq (caar parse-spec) 'PROG) (eval (cadar parse-spec))) ((eq (caar parse-spec) 'REGEXP) (cond ;; Is it a match? (The regexp must be anchored at the end of a line). ((and (looking-at (cadar parse-spec)) (progn (goto-char (match-end 0)) (eolp))) [...] The one reason I can think of is that the cXr functions are defined by "cl.el", and pcl-cvs is supposed to be compatible with GNU Emacs also... But they have "cl.el" too, so why not? Another question that comes to mind is "Why aren't the cXr accessors subrs?" It seems like that would be way faster, and there may be code that would benefit from it. Is there any advantage in converting (function (lambda () ...)) to #'(lambda () ...) other than for readability? Or `((, var) ...) to #`(,var ...)?

1 participants
0 comments

Is anyone using gud? 26 years, 3 months

SL Baur

There's gdb.el/gdbsrc.el for GDB and the EOS stuff for DBX. Is anyone using gud? Is the XEmacs version usable?

3 participants
2 comments

Re: Macros: Scheme vs Common Lisp 26 years, 3 months

Craig Lanning

At 07:13 AM 8/27/98 -0400, Rick Campbell wrote: >Run Plugin:"c:\users\craig\mail\attach\Re Macros Scheme vs Common Li1.ems <0880.0002>" >Content-Type: text/plain; charset=US-ASCII > > From: sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) > Date: 26 Aug 1998 14:20:32 +0200 > > . . . > > I suspect your CL actually processes the forms in some weird > order. In any case, I strongly doubt that the CL standard > mandates the behavior you describe. > >Common Lisp does not mandate much of anything regarding when expansion >occurs. It's an implementation detail, i. e. you should not write >code that depends on expansion happening at a certain time. > > Rick That's not really true. All forms are processed in order from left to right. Macros are expanded as they are reached. In compiled code, macros are expanded at compile time in such a way as not be expanded at runtime. Craig Lanning E-Mail: CraigL(a)InternetX.net

2 participants
1 comments

Re: Is anyone using gud? 26 years, 3 months

SL Baur

Rick Campbell <campbell(a)cyberpass.net> writes in xemacs-beta(a)xemacs.org: > I use it sometimes. It's pretty bad, but sometimes it's the only > choice when dealing with SparcWorks C++. O.K. "Bad but usable" doesn't sound like a burning reason to trash it. > gdb-mode isn't practical because of name mangling issues, and > painful as it is, I prefer running dbx through gud than any other > interface I've tried. If there's a better way to run dbx in emacs > -- especially if it looks a lot like gdb-mode, *please* let me > know. There's the Sparcworks stuff. I've done a minimal[1] port of gud.el from Emacs 20.3 but there are enough issues[2] with it to defer integration until post 21.0. Footnotes: [1] GUIless. [2] It requires a different version of speedbar than the one we have, and it will require a change to etags.el for sdb support.

2 participants
1 comments

Re: Macros: Scheme vs Common Lisp 26 years, 3 months

Karl M. Hegbloom

Well, you've got me reading the HyperSpec again. :-) It's such a thick book. The macro stuff sounds interesting... It sounds like you can define a macro, and the expander function is closed in the defining lexical environment, but that you can pass in an arbitrary environment at expansion time somehow... Hmmm. I'm too new at this to see how that would be used in practice. Guess I'll come across it someday. :-)

2 participants
1 comments

Re: Macros: Scheme vs Common Lisp 26 years, 3 months

Michael Sperber

>>>>> "Holger" == Holger Schauer <schauer(a)coling.uni-freiburg.de> writes: >>>>> "MS" == Michael Sperber schrieb am 26 Aug 1998 12:14:52 +0200: MS> Can you explain to me why the above should lead to a different MS> result? CLISP's output is exactly what I expected it to be: MS> (setq bar 23) MS> (defmacro foo () bar) ; this means (foo) expands to the value of BAR Holger> Isn't this meant to mean to refer to the current binding of bar, which Holger> in this case happens to be 23 ? What do you mean by "current"? BAR is supposed to refer to the binding introduced by (setq bar 23), which is the lexically enclosing one. The question is: when is the binding resolved? MS> (defun baz () (foo)) ; this therefore expands to (defun baz () 23) ^^^^^^^^^^^^^^^^^ This is the crux of the matter: Does the binding get resolved here? MS> (baz) => 23 ; indeed MS> (setq baz 42) ; the definition of FOO is unchanged Holger> (I guess you mean bar, not baz). Yes. Holger> You are right, the definition of FOO is unchanged, it still Holger> refers to the current binding of bar - which now happens to be Holger> 42. Sure, but I expanded FOO before I changed the binding. I suspect your CL actually processes the forms in some weird order. In any case, I strongly doubt that the CL standard mandates the behavior you describe. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

3 participants
2 comments

Re: Macros: Scheme vs Common Lisp 26 years, 3 months

Michael Sperber

>>>>> "Craig" == Craig Lanning <CraigL(a)internetx.net> writes: Craig> At 09:33 AM 8/25/98 +0200, Michael Sperber [Mr. Preprocessor] wrote: >>>>>>> "Clemens" == Clemens Heitzinger <cheitzin(a)rainbow.studorg.tuwien.ac.at> writes: >> Clemens> What is "the right thing"? >> >> I'll say it once again: The right thing is that macros respect the >> same scoping rules as the underlying language. Craig> Which time? Scoping rules get applied to CL macros twice, once when the Craig> macro function is executed, and again when the result of the macro is Craig> executed. (Let's remember, a macro is just a function that returns an Craig> executable form as its value.) Well, the lexical environment of the macro definition only gets applied to the *definition* of the macro. The lexical environment of the *use* gets applied to its expansion. This is contrary to how lexical scoping normally works, the body of a function (corresponding to the body, i.e. expansion of a macro) is executed in the lexical environment of its definition, not of its use. Craig> It seems that we are approaching the point where we "agree to disagree". Craig> The CL people are used to doing macros the CL way and, Craig> consequently, don't see much benefit to the Scheme method of Craig> doing macros. The Scheme people, on the other hand, are used Craig> to doing macros the Scheme way and don't see much benefit to Craig> the CL method of doing macros. We have each learned to work Craig> around the deficiencies of our preferred Lisp environments. I don't see the difference here. I definitely see the benefits of CL macros, which are very powerful and expressive. There are things you cannot do with Scheme macros because of the constraints of the pattern language. However, there are two nits I have with it: - It is not expressive enough to make macros obey standard CL scoping. - It is too expressive in the sense that even with very simple macros, you have to take special care to avoid potential name capture problems. This is especially concerning as a name capture bug can show up years after the macro definition has been written. Scheme takes the stance that there are two approaches to doing macros: a high-level approach (as standardized by R5RS), and a low-level approach. Ideally, the high-level macro system can be implemented with the low-level system. Designing a decent low-level macro system is very difficult, which is why there's no standard yet. (Even though things have boiled down to 2 or 3 alternatives by now.) CL-style macros are not powerful enough to express Scheme high-level macros. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: How do I verify that gc is doing anything 26 years, 3 months

Hrvoje Niksic

Andy Piper <andyp(a)parallax.co.uk> writes: > If I start gnus using movemail to read my mail my xemacs image size > grows from about 8Mb to 20-30Mb (this is with a fixed cygwin from > Chris Faylor). If I quit gnus the memory usage does not go down at > all. Is this what people would expect? Unfortunately, yes. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Speak softly and carry a +6 two-handed sword.

1 participants
0 comments

Re: Enormous memory leak 26 years, 3 months

Colin Rafferty

Darryl Okahata writes: > Jan Vroonhof <vroonhof(a)math.ethz.ch> wrote: >> Darryl Okahata <darrylo(a)sr.hp.com> writes: >> >> > [2 leaks <text/plain; US-ASCII (quoted-printable)>] >> > MLK: 304000 bytes leaked at 0x401bc638 >> > * This memory was allocated from: >> > malloc [rtlib.o] >> > xmalloc [alloc.c:390] >> > regex_compile [regex.c:3099] >> > re_compile_pattern [regex.c:5953] >> > compile_pattern_1 [search.c:143] >> > compile_pattern [search.c:186] >> > string_match_1 [search.c:387] >> >> It does look pretty suspect. There is loads of 'passing the pointer >> being done'. How rare are systems without REGEX_MAY_ALLOC? I suspect >> this case is exercised less. However it migth well be that the >> particular rexexp ist just never GCed. > Well, if it is a real memory leak, it's not being caused by GC. > This particular memory block is part of a non-lisp global variable. > However, I can't find any place where this leak could be caused. I'm > wondering if temacs is zero'ing some global memory before it exit()'s > (in which case this would not be a real leak). I peeked a little at the code, and from that and some half-remembered conversation, it seems that we are caching compiled regular expressions, and dumping the least-recently-used one when the regexp is not in the cache. While at first it seems as if we are only overwriting the LRU buffer, and not actually clearing it, it turns out that deep in the dark recesses of `regex_compile', it is reusing the buffer anyway. So the "leak" is most likely just because of the global cache, and not an actual leak. I think. > If I have time (which I probably don't), I'll try to step through > temacs to see where the leak is occurring. If you could call the functions to have purify report leaks on the fly, rather than only at exit, that should help a lot. On the other hand, searching for leaks is expensive. I notice that there is a -with-quantify compile flag. Maybe I should make a purify one, and see what happens. -- Colin

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 August 1998