August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Enormous memory leak 25 years, 8 months

Jan Vroonhof

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. A few of the other ones seem to be in the image code, that is pretty new. Jan

2 participants
1 comments

Should 'package-*' install into user dir and other questions? 25 years, 8 months

Jan Vroonhof

I guess this got overlooked as everybody here is is own 'sysadmin' Isn't joe user supposed to be able to fetch packages he needs himself and put them ~/.xemacs. 1. Shouldn't there be a variable package-admin-install-site-wide defaulting to nil if non-root? 1a. Shouldn't the package-* command always prompt for the path, default depending on the value package-admin-install-site-wide 2. Shouldn't the package code put mule packages in mule packages and on request other packages in site-packages? 3. Shouldn't package-get-update-all respect the previous location of the package if possible. 4. Wasn't add_binary_package suppossed to be in lisp now? 5. Shouldn't add_binary_package delete the old version even in 21.0? Jan

2 participants
1 comments

Re: dumb question 25 years, 8 months

Adrian Aichner

>>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes: Hello Andy, AFAIK the more general way to make Gnus cooperate with related packages like BBDB, TM, Mailcrypt, etc. is to (require 'gnus-setup) The default variable settings in gnus-setup suffice to get TM. Here is the documentation :-) : (find-file (locate-library "gnus-setup.el")) HTH, Adrian Andy> How do I use tm with gnus? All of the info nodes on this are empty. Andy> andy Andy> --------------------------------------------------------------------------- Andy> " .sigs are like your face - rarely seen by you and uglier than you think" Andy> Dr Andy Piper, Technical Architect, Parallax Solutions Ltd Andy> mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail aichner(a)ecf.teradyne.com

1 participants
0 comments

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

Andy Piper

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? What does it look like on a UNIX machine? I'm just wondering whether GC is actually collecting anything and how I prove whether it is. 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

2 participants
1 comments

Re: Enormous memory leak 25 years, 8 months

Darryl Okahata

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. Note that this was under HP-UX 10.20, and not under cygwin. These memory leaks, if real, probably exist on most (all?) platforms. -- Darryl Okahata darrylo(a)sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day.

1 participants
0 comments

Re: [Success+Problem] "Finnish Landrace" `sparc-sun-solaris2.6' 25 years, 8 months

Gunnar Evermann

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > >>>>> "P" == P E Jareth Hein <jareth(a)camelot.co.jp> writes: > > P> This is indicative of something that isn't supposed to be able to > P> happen. I'll look again at the code in question, but I thought I was > P> pretty thourough last time... :-( Could you perhaps send me the > P> output of 'xdpyinfo' so I can get a little info on your X server? > I got this too in emacs-version "21.0 \"Finnish Landrace\" XEmacs > Lucid". > > It may have well occured while I was viewing some JPEG images, but I > can't be sure now. Hi Jareth, me too! :-) I can reproduce it by starting XEmacs and then going to the default Page of W3 (William Perry's page in Indiana). There is a JPEG which causes this. BTW: this is also solaris2.6 I put a breakpoint at object-x.c:199 and had a look at color_def and cells[nearest] : *color_def = { pixel = 55U red = 55512U green = 53713U blue = 50886U flags = '\007' pad = 'û' } cells[20] = { pixel = 20U red = 55512U green = 53713U blue = 50886U flags = '\007' pad = ')' } I have no idea why XAllocColor() fails, but it DOES happen :-) If you'd like any further info, drop me a mail. Gunnar name of display: :0.0 version number: 11.0 vendor string: Sun Microsystems, Inc. vendor release number: 3600 maximum request size: 262140 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, MSBFirst, 32 image byte order: MSBFirst number of supported pixmap formats: 2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 keycode range: minimum 8, maximum 132 focus: window 0x5400030, revert to Parent number of extensions: 21 AccessX Adobe-DPS-Extension DOUBLE-BUFFER DPSExtension MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD Multi-Buffering SHAPE SUN_ALLPLANES SUN_DGA SUN_OVL SUN_SME SYNC SolarisIA X3D-PEX XC-MISC XIE XInputDeviceEvents XInputExtension XTEST default screen number: 0 number of screens: 1 screen #0: dimensions: 1152x900 pixels (325x254 millimeters) resolution: 90x90 dots per inch depths (2): 1, 8 root window id: 0x2a depth of root window: 8 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x21 default number of colormap cells: 256 preallocated pixels: black 1, white 0 options: backing-store YES, save-unders YES largest cursor: unlimited current input event mask: 0x78003f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask number of visuals: 6 default visual id: 0x22 visual: visual id: 0x22 class: PseudoColor depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits visual: visual id: 0x23 class: DirectColor depth: 8 planes available colormap entries: 8 per subfield red, green, blue masks: 0x7, 0x38, 0xc0 significant bits in color specification: 8 bits visual: visual id: 0x24 class: GrayScale depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits visual: visual id: 0x25 class: StaticColor depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x7, 0x38, 0xc0 significant bits in color specification: 8 bits visual: visual id: 0x26 class: TrueColor depth: 8 planes available colormap entries: 8 per subfield red, green, blue masks: 0x7, 0x38, 0xc0 significant bits in color specification: 8 bits visual: visual id: 0x27 class: StaticGray depth: 8 planes available colormap entries: 256 red, green, blue masks: 0x0, 0x0, 0x0 significant bits in color specification: 8 bits

1 participants
0 comments

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

Jan Vroonhof

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? Jan

1 participants
0 comments

[GOOD PATCH][PATCH] [21.1 or 21.2] Re: MH and TM -- article-XXX buffer annoyance 25 years, 8 months

Darryl Okahata

[ AARRGGH! Brain fart! I sent the wrong patch in my previous message. This is the good one. ] Rick Campbell <campbell(a)cyberpass.net> wrote: > Thanks. I'll try to check it out. In the mean time, I think I've > corrected the problem with the attached patch. At least, I've been > going through a bunch of mail and have not seen the `buffer modified' > warning since I made this change to mh-display-msg. Eeep! You're right -- tm-mh-e.el does need to be fixed (I've got it fixed in my local copy, but it seems that I've never submitted it). Here's the correct patch. 1998-08-27 Darryl Okahata <darrylo(a)sr.hp.com> * tm/tm-mh-e.el: Fixed problem where buffer-modified-p was being reset too early. -- Darryl Okahata darrylo(a)sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day.

1 participants
0 comments

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

Karl M. Hegbloom

>>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes: Andy> If I start gnus using movemail to read my mail my xemacs Andy> image size grows from about 8Mb to 20-30Mb (this is with a Andy> fixed cygwin from Chris Faylor). If I quit gnus the memory Andy> usage does not go down at all. Is this what people would Andy> expect? What does it look like on a UNIX machine? I'm just Andy> wondering whether GC is actually collecting anything and how Andy> I prove whether it is. Here I've started `gnus', read a few articles, quit `gnus', looked at some jpegs with `v' from `dired', and along the way checked the memory footprint. It shows SIZE and RSS going up and down, so memory is being malloc()'d and free()'d for certian. (Linux 2.0.35) If I visit a very large file, then kill the buffer it was in, the SIZE goes up then down by a significant amount. karlheg＠bittersweet:~ % ps wmax | pgrep 'RSS|[x]emacs ' PID TTY MAJFLT MINFLT TRS DRS SIZE SWAP RSS SHRD LIB DT COMMAND 11844 ? 7694 236880 3488 16156 19644 0 19644 3912 0 3932 xemacs -f gnuserv-start karlheg＠bittersweet:~ % ps wmax | pgrep 'RSS|[x]emacs ' PID TTY MAJFLT MINFLT TRS DRS SIZE SWAP RSS SHRD LIB DT COMMAND 11844 ? 7849 237210 3488 16352 19840 0 19840 3912 0 3981 xemacs -f gnuserv-start karlheg＠bittersweet:~ % ps wmax | pgrep 'RSS|[x]emacs ' PID TTY MAJFLT MINFLT TRS DRS SIZE SWAP RSS SHRD LIB DT COMMAND 11844 ? 7866 238584 3488 16608 20096 0 20096 3912 0 4045 xemacs -f gnuserv-start karlheg＠bittersweet:~ % ps wmax | pgrep 'RSS|[x]emacs ' PID TTY MAJFLT MINFLT TRS DRS SIZE SWAP RSS SHRD LIB DT COMMAND 11844 ? 7881 240715 3488 16372 19860 0 19860 3912 0 3986 xemacs -f gnuserv-start karlheg＠bittersweet:~ % ps wmax | pgrep 'RSS|[x]emacs ' PID TTY MAJFLT MINFLT TRS DRS SIZE SWAP RSS SHRD LIB DT COMMAND 11844 ? 7925 244613 3488 16544 20032 0 20032 3912 0 4029 xemacs -f gnuserv-start You have new mail. karlheg＠bittersweet:~ % ps wmax | pgrep 'RSS|[x]emacs ' PID TTY MAJFLT MINFLT TRS DRS SIZE SWAP RSS SHRD LIB DT COMMAND 11844 ? 7950 245854 3488 16440 19928 0 19928 3912 0 4003 xemacs -f gnuserv-start karlheg＠bittersweet:~ % ps wmax | pgrep 'RSS|[x]emacs ' PID TTY MAJFLT MINFLT TRS DRS SIZE SWAP RSS SHRD LIB DT COMMAND 11844 ? 8032 247203 3488 17268 20756 0 20756 3912 0 4210 xemacs -f gnuserv-start karlheg＠bittersweet:~ % ps wmax | pgrep 'RSS|[x]emacs ' PID TTY MAJFLT MINFLT TRS DRS SIZE SWAP RSS SHRD LIB DT COMMAND 11844 ? 8032 247337 3488 16616 20104 0 20104 3912 0 4047 xemacs -f gnuserv-start karlheg＠bittersweet:~ %

1 participants
0 comments

Re: dumb question 25 years, 8 months

Karl M. Hegbloom

>>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes: Andy> How do I use tm with gnus? All of the info nodes on this are Andy> empty. ~/.gnus: (require 'mime-setup)

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