August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Seppuku and x_IO_error_handler() 25 years, 8 months

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > As I see it, here's what could happen: > > - If you have a non X console connection somewhere, killing an existing X frame > won't indeed kill xemacs, but is likely to delete all X frames. > > - If you don't have any non X connections, xemacs will be killed all the same. I'm afraid you are right. The "correct" behaviour is that killing an existing X frame deletes all the X frames *on that display*, not on all displays. If you have only X frames running, it is normal that XEmacs will exit -- as you say it yourself, that's how X handles killing. I have now tried my patch with multiple X connections and the result is, well, bogus. Still, I believe my patch should be applied because it at least attempts to bring some order to the situation, and makes things work with the TTY consoles. > The real pain is that X considers it fatal to loose a connection, > even in the case you have several ones. Yuck! Is there a way around that? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- A professor is one who talks in someone else's sleep.

1 participants
0 comments

Re: Seppuku and x_IO_error_handler() 25 years, 8 months

Didier Verna

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Didier Verna <verna(a)inf.enst.fr> writes: > > > > The right solution is for x_IO_error_handler to throw to top level > > > without ever returning to Xlib. > > > > This sounds like it will fix your problem, but not the case where > > one of *multiple* X connections (either local or remote) is killed, > > right ? > > Why? I thought it would fix both. I haven't tested it yet, though. Because of a painfull limitation of the intrinsics: when a fatal error occurs either the library exists the application, or you have installed a personnal error handler and this handler is not supposed to return (most important: further calls to Xlib will lead to undefined results). As a consequence, your fix actually benefits from the fact that you have "somewhere else" to return, namely a non X Window console connection, which is not always the case. As I see it, here's what could happen: - If you have a non X console connection somewhere, killing an existing X frame won't indeed kill xemacs, but is likely to delete all X frames. - If you don't have any non X connections, xemacs will be killed all the same. The real pain is that X considers it fatal to loose a connection, even in the case you have several ones. I'll apply your patch and check if my predictions are right. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: How do I verify that gc is doing anything 25 years, 8 months

Hrvoje Niksic

Andy Piper <andyp(a)parallax.co.uk> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > 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. > > Why? Because Lisp storage is not reclaimed by the system. > It sounds like this is not the behaviour under NTemacs and UNIX. I don't think my XEmacs shrinks back to 8M after I quit Gnus. In fact, I am fairly certain I've never seen that happen. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Be nice to your kids. They'll choose your nursing home.

1 participants
0 comments

Re: Seppuku and x_IO_error_handler() 25 years, 8 months

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > > The right solution is for x_IO_error_handler to throw to top level > > without ever returning to Xlib. > > This sounds like it will fix your problem, but not the case where > one of *multiple* X connections (either local or remote) is killed, > right ? Why? I thought it would fix both. I haven't tested it yet, though. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Listen, kid, we're all in it together!" -- Harry Tuttle in _Brazil_

1 participants
0 comments

Re: How do I verify that gc is doing anything 25 years, 8 months

Andy Piper

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > 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). > > I guess this memory is mostly from the huge buffers gnus uses for its folders > > > If I quit gnus the memory usage does not go down at all. > > Is this what people would expect? > > gc collect does not give memory back to the system. On some systems > (most unix systems that support mmap for instance) XEmacs does give > the memmory from deleted buffers back. > > Maybe on your system it doesn't. What allocator does XEmacs use on cygwin? gmalloc. andy -- --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

1 participants
0 comments

Re: How do I verify that gc is doing anything 25 years, 8 months

Andy Piper

Hrvoje Niksic <hniksic(a)srce.hr> writes: > 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. Why? It sounds like this is not the behaviour under NTemacs and UNIX. andy -- --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

1 participants
0 comments

Re: Enormous memory leak 25 years, 8 months

Andy Piper

Darryl Okahata <darrylo(a)sr.hp.com> writes: > --Multipart_Thu_Aug_27_10:47:48_1998-1 > Content-Type: text/plain; charset=US-ASCII > > Andy Piper <andyp(a)parallax.co.uk> wrote: > > > I think this is probably cygwin related. I am seeing my XEmacs process grow > > to be huge - 50Mb with no buffers open. > > Well, some time back, I ran purify on "Erzgeberg-pre1", and purify > complained about numerous (and large!) memory leaks. However, I haven't > had the time to verify that these really are memory leaks (as purify is > being run on temacs, and not the dumped xemacs). I've attached a few > instances of the larger memory leaks; perhaps someone could look into > them. Thanks, I've fixed the png one now. The others look like GC stuff I don't understand. > Note that this was under HP-UX 10.20, and not under cygwin. These > memory leaks, if real, probably exist on most (all?) platforms. I think there is a fundamental problem under cygwin (maybe native as well?) that means that no lisp storage gets returned to the system. andy -- --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

1 participants
0 comments

Re: Seppuku and x_IO_error_handler() 25 years, 8 months

Didier Verna

Hrvoje Niksic <hniksic(a)srce.hr> writes: > * 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. [...] > The right solution is for x_IO_error_handler to throw to top level > without ever returning to Xlib. This sounds like it will fix your problem, but not the case where one of *multiple* X connections (either local or remote) is killed, right ? For this, I've planned to experiment some *jmp stuff when I'm less busy than today. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: Is anyone using gud? 25 years, 8 months

SL Baur

Rick Campbell <campbell(a)cyberpass.net> writes in xemacs-beta(a)xemacs.org: ... > Of course it would be wonderful to have tooltalk-free dbx support that > was as nice as gdb-mode. It's being worked on (by me), but it won't appear very fast. > However, I don't think it's available and I'm not holding my breath > or volunteering, so I'm happy enough to make do with gud until I can > ditch the old Sun environment. Fair enough.

1 participants
0 comments

Re: External widget may need to be compiled with -DXTHREADS 25 years, 8 months

Colin Rafferty

Glynn Clements writes: > I thought that I'd have a look at the external widget feature. > After a fair amount of debugging core dumps, I figured that you need > to use -DXTHREADS if it was used for compiling libXt. This is only the case if your X library is thread-safe. When I first got to my current job, they had the thread-safe X libraries, but we needed to use the -DXTHREADS option. However, after they reinstalled the system, we no longer needed that option. > It would be useful if someone who understands autoconf better than I > do could figure out how to get the value of ProjectThreadsDefines from > xmkmf and stick it in the compilation command for src/extw-Xt.c. I don't know enough about the X installation to know what the right thing to do is. I haven't installed X since 1990. -- Colin

2 participants
1 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