11:52 a.m.
Hi all,
found a slight problem tonight -- seems to be a gc-related
memory leak in 21.5.b16:
$ /usr/ucb/ps -auxwww |grep xemacs
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
jmcp 17583 0.0 58.9968632600680 ? T Jan 06 11:18
/usr/local/bin/xemacs -geometry 90x65+0+0
jmcp 17585 0.0 0.0 1920 4 pts/6 S Jan 06 0:00
/d00/xemacs/lib/xemacs-21.5-b16/i386-pc-solaris2.9/gnuserv
$ ps -o user,pid,pcpu,pmem,vsz,rss,osz,comm -p 17583,17585
USER PID %CPU %MEM VSZ RSS SZ COMMAND
jmcp 17583 0.0 63.8 968632 650592 242158 /usr/local/bin/xemacs
jmcp 17585 0.0 0.0 1920 4 480
/d00/xemacs/lib/xemacs-21.5-b16/i386-pc-solaris2.9/gnuserv
espresso:d01 $ pstack 17583
17583: /usr/local/bin/xemacs -geometry 90x65+0+0
0809756f Fgarbage_collect () + 803
00000000 ???????? ()
Once gcore of 17583 had finished (20mins later!) I ran
dbx over it:
espresso:jmcp $ dbx /d00/xemacs/bin/xemacs-21.5-b16 /home/jmcp/core.17583
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.1' in
your .dbxrc
Reading xemacs-21.5-b16
core file header read successfully
Reading ld.so.1
Reading libtiff.so.3
Reading libpng.so.2.1.0.15
Reading libjpeg.so.62.0.0
Reading libz.so.1
Reading libXpm.so.4
Reading libgtk-1.2.so.0.9.1
Reading libgdk-1.2.so.0.9.1
Reading libgmodule-1.2.so.0.0.10
Reading libglib-1.2.so.0.0.10
Reading libdl.so.1
Reading libXext.so.0
Reading libX11.so.4
Reading libsocket.so.1
Reading libnsl.so.1
Reading libm.so.1
Reading libcurses.so.1
Reading libelf.so.1
Reading libgen.so.1
Reading libc.so.1
Reading libm.so.2
tï¼ null (lï¼ 1) program terminated by signal 0 (UNKNOWN SIGNAL)
0x0809756f: Fgarbage_collect+0x0803: movl (%edx),%edx
dbx: core file read error: address 0x6565726a not in data space
dbx: attempt to read frame failed -- cannot get return address
0x08133de9: Fdo_auto_save+0x0969: addl $0xc,%esp
(dbx) where
dbx: core file read error: address 0x6565726a not in data space
dbx: attempt to read frame failed -- cannot get return address
[1] Fgarbage_collect(0x4345524c, 0x5f44524f, 0x45455246), at 0x809756f
=>[2] Fdo_auto_save(), at 0x8133de9
[3] 0x0(), at 0xffffffff
which doesn't tell _me_ much but it might (I hope) help you.
My Installation file is at
http://espresso.jjcma.isa-geek.com/Installation.gtk.working
and the mdb disassembly is at
http://espresso.jjcma.isa-geek.com/Fgarbage_collect.txt
cheers,
James C. McPherson
11:39 a.m.
>>>> "James" == James C McPherson
<james.mcpherson(a)optusnet.com.au> writes:
James> My Installation file is at
James> http://espresso.jjcma.isa-geek.com/Installation.gtk.working
I've been getting timeouts on this URL for the last 10 hours or so. Is
something amiss?
Malcolm
--
Malcolm Purvis <malcolmpurvis(a)optushome.com.au>
Q: Why did the chicken cross the Mobius strip?
A: To get to the other... uh... err...
8:31 p.m.
Malcolm Purvis wrote:
>>>>>"James" == James C McPherson
<james.mcpherson(a)optusnet.com.au> writes:
James> My Installation file is at
James> http://espresso.jjcma.isa-geek.com/Installation.gtk.working
I've been getting timeouts on this URL for the last 10 hours or so. Is
something amiss?
yeah - I'd misconfigured ddclient so an nslookup of
jjcma.isa-geek.com (hosted by dyndns) was returning
192.168.1.65 -- espresso's ip ;|
Try it now - should work somewhat better.
cheers,
James
11:06 a.m.
James C. McPherson wrote:
Malcolm Purvis wrote:
>>>>>> "James" == James C McPherson
<james.mcpherson(a)optusnet.com.au>
>>>>>> writes:
> James> My Installation file is at
> James> http://espresso.jjcma.isa-geek.com/Installation.gtk.working
> I've been getting timeouts on this URL for the last 10 hours or so. Is
> something amiss?
yeah - I'd misconfigured ddclient so an nslookup of
jjcma.isa-geek.com (hosted by dyndns) was returning
192.168.1.65 -- espresso's ip ;|
Try it now - should work somewhat better.
Ok, third time lucky I hope!
http://espresso.jjcma.isa-geek.com:80/Installation.gtk.working
James
11:33 a.m.
On 2004-01-12 12:06, James C. McPherson wrote:
Ok, third time lucky I hope!
http://espresso.jjcma.isa-geek.com:80/Installation.gtk.working
No luck.
1:49 a.m.
>>>> "Mats" == Mats Larsson
<mats.larsson(a)ericsson.com> writes:
Mats> On 2004-01-12 12:06, James C. McPherson wrote:
> Ok, third time lucky I hope!
> http://espresso.jjcma.isa-geek.com:80/Installation.gtk.working
Mats> No luck.
No luck from here, either ("connection refused").
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
5:25 a.m.
>>>> "James" == James C McPherson
<james.mcpherson(a)optusnet.com.au> writes:
James> Hi all, found a slight problem tonight -- seems to be a gc-related
James> memory leak in 21.5.b16
I've been trying to replicate this but haven't has much success so I 'm
trying
to work out what's missing.
Does this occur is you use xemacs -vanilla?
Do you run any lisp code that runs things every now and then (gnus daemons,
timers, etc)?
Thanks,
Malcolm
--
Malcolm Purvis <malcolmpurvis(a)optushome.com.au>
Q: Why did the chicken cross the Mobius strip?
A: To get to the other... uh... err...
10:20 a.m.
Malcolm Purvis wrote:
>>>>>"James" == James C McPherson
<james.mcpherson(a)optusnet.com.au> writes:
James> Hi all, found a slight problem tonight -- seems to be a gc-related
James> memory leak in 21.5.b16
I've been trying to replicate this but haven't has much success so I 'm
trying
to work out what's missing.
Does this occur is you use xemacs -vanilla?
Do you run any lisp code that runs things every now and then (gnus daemons,
timers, etc)?
Hi all,
haven't had a chance to try to replicate this one yet -
work has been busy so no chance for coding.
I don't know whether -vanilla helps, and as far as I
am aware I am not running anything except gnuserv which
runs with timers or whatever.
Here's what I was doing:
load up a jsp I'm working on
turn this buffer to xml-mode
C x 5 2 and startup a shell (my login shell is /bin/ksh)
. ~/.profile
leave it overnight (7 or so hours)
come in in the morning and check the memory usage -- large.
ciao,
James
7:11 a.m.
>>>> "James" == James C McPherson
<james.mcpherson(a)optusnet.com.au> writes:
James> Hi all, found a slight problem tonight -- seems to be a
James> gc-related memory leak in 21.5.b16
James> haven't had a chance to try to replicate this one yet -
James> work has been busy so no chance for coding.
James> I don't know whether -vanilla helps, and as far as I am
James> aware I am not running anything except gnuserv which runs
James> with timers or whatever.
James> Here's what I was doing:
James> load up a jsp I'm working on turn this buffer to xml-mode C
James> x 5 2 and startup a shell (my login shell is /bin/ksh)
James> . ~/.profile
James> leave it overnight (7 or so hours)
James> come in in the morning and check the memory usage -- large.
There was a similar report a while ago, but it was also not replicable
by anyone else. :-(
If you compile a debug configuration, you can run M-x
show-memory-usage. If you would run it as soon as you start up and
after XEmacs has ballooned up, and compare the sizes according to ps,
we can possibly discover where the memory is going.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
10:51 p.m.
Stephen J. Turnbull wrote:
>>>>>"James" == James C McPherson
<james.mcpherson(a)optusnet.com.au> writes:
James> Hi all, found a slight problem tonight -- seems to be a
James> gc-related memory leak in 21.5.b16
James> haven't had a chance to try to replicate this one yet -
James> work has been busy so no chance for coding.
James> I don't know whether -vanilla helps, and as far as I am
James> aware I am not running anything except gnuserv which runs
James> with timers or whatever.
James> Here's what I was doing:
James> load up a jsp I'm working on turn this buffer to xml-mode C
James> x 5 2 and startup a shell (my login shell is /bin/ksh)
James> . ~/.profile
James> leave it overnight (7 or so hours)
James> come in in the morning and check the memory usage -- large.
There was a similar report a while ago, but it was also not replicable
by anyone else. :-(
If you compile a debug configuration, you can run M-x
show-memory-usage. If you would run it as soon as you start up and
after XEmacs has ballooned up, and compare the sizes according to ps,
we can possibly discover where the memory is going.
Ok, I've attached 3 show-memory-usage outputs. One from startup,
one from 8 hours later, and one from 25 hours. I haven't been
using xemacs in this time, merely leaving it running.
Next I'll try with --vanilla.
cheers,
James
buffer text markers extents other total
-------------------------------------------------------------------
SCmembership.java 49296 312 0 512 50120
*Minibuf-0* 2048 480 0 512 3040
*shell* 2048 312 0 512 2872
*scratch* 32 264 0 512 808
*Echo Area* 2060 72 0 512 2644
*pixmap conversion* 4108 72 0 512 4692
*Message-Log* 2060 72 0 512 2644
*Gutter Area* 2060 72 0 512 2644
*memory usage* 4108 72 0 512 4692
total 67820 1728 0 4608 74156
window face-cache glyph-cache scrollbar-instances line-start-cache
other-redisplay other total
--------------------------------------------------------------------------------------------------------------------------
#<window on "SCmembershi 2080 544 192
1068 328028 1088 333000
#<window on " *Minibuf-0 544 160 0
160 18928 1100 20892
total 2624 704 192 1228
346956 2188 353892
object storage
----------------------------------------
cons 2734872
symbol 437416
compiled-function 243360
short-string 1794048
long-strings-total-length 21089
string-header 930452
float 136948
marker 163520
event 202592
extent 139264
free 0
GtkObject 144
ffi 3024
face 5624
glyph 5192
image-instance 7040
font-instance 352
color-instance 532
scrollbar-instance 112
toolbar-button 1320
gui-item 256
window-mirror 208
window 1656
frame 348
device 344
console 464
specifier 68368
timeout 80
command-builder 52
keymap 8040
extent-auxiliary 7728
extent-info 500
buffer 3640
opaque-ptr 16
opaque 82448
range-table 16
char-table 36040
process 224
stream 984
hash-table 35904
bit-vector 16
weak-list 29112
lcrecord-list 888
vector 480828
symbol-value-buffer-local 12132
symbol-value-varalias 476
total 7597669
grand total: 8025717
buffer text markers extents other total
-------------------------------------------------------------------
SCmembership.java 49296 504 0 512 50312
*Minibuf-0* 2048 576 0 512 3136
*shell* 2060 312 0 512 2884
*scratch* 32 216 0 512 760
*Echo Area* 2060 72 0 512 2644
*pixmap conversion* 4108 72 0 524 4704
*Message-Log* 2048 72 0 512 2632
*Gutter Area* 2048 60 0 512 2620
*Completions* 2048 120 0 512 2680
*substitute* 32 72 0 512 616
*memory usage* 4108 72 0 512 4692
total 69888 2148 0 5644 77680
window face-cache glyph-cache scrollbar-instances line-start-cache
other-redisplay other total
--------------------------------------------------------------------------------------------------------------------------
#<window on "SCmembershi 2080 544 192
1056 303596 1112 308580
#<window on " *Minibuf-0 544 160 0
160 18928 1100 20892
total 2624 704 192 1216
322524 2212 329472
object storage
----------------------------------------
cons 2734872
symbol 437416
compiled-function 243360
short-string 1794048
long-strings-total-length 21089
string-header 930452
float 136948
marker 163520
event 202592
extent 139264
free 0
GtkObject 144
ffi 3024
face 5624
glyph 5192
image-instance 7168
font-instance 352
color-instance 532
scrollbar-instance 112
toolbar-button 1320
gui-item 256
window-mirror 208
window 1656
frame 348
device 344
console 464
specifier 68368
timeout 80
command-builder 52
keymap 8040
extent-auxiliary 10864
extent-info 560
buffer 3920
opaque-ptr 16
opaque 83620
range-table 16
char-table 36040
process 224
stream 984
hash-table 36032
bit-vector 16
weak-list 29112
lcrecord-list 888
vector 481460
symbol-value-buffer-local 12240
symbol-value-varalias 476
total 7603313
grand total: 8010465
buffer text markers extents other total
-------------------------------------------------------------------
*scratch* 32 336 0 524 892
*Minibuf-0* 32 288 0 512 832
*Echo Area* 2048 72 0 512 2632
*pixmap conversion* 4108 72 0 512 4692
*Message-Log* 2060 72 0 512 2644
*memory usage* 4108 72 0 512 4692
total 12388 912 0 3084 16384
window face-cache glyph-cache scrollbar-instances line-start-cache
other-redisplay other total
--------------------------------------------------------------------------------------------------------------------------
#<window on "*scratch*" 544 544 192
160 20360 1088 22888
#<window on " *Minibuf-0 544 160 0
160 10712 1088 12664
total 1088 704 192 320
31072 2176 35552
object storage
----------------------------------------
cons 1857996
symbol 390404
compiled-function 241332
short-string 1794048
long-strings-total-length 21089
string-header 918236
float 8176
marker 38836
event 187008
extent 4096
free 0
GtkObject 72
face 5244
glyph 5016
image-instance 6016
font-instance 352
color-instance 280
scrollbar-instance 56
toolbar-button 1320
window-mirror 104
window 1104
frame 348
device 344
console 464
specifier 64416
timeout 80
command-builder 52
keymap 7600
extent-auxiliary 4368
extent-info 180
buffer 2520
opaque-ptr 16
opaque 48192
range-table 16
char-table 31800
process 112
stream 536
hash-table 34176
bit-vector 16
weak-list 27384
lcrecord-list 768
vector 473032
symbol-value-buffer-local 9468
symbol-value-varalias 476
total 6187149
grand total: 6239085
8:55 a.m.
>>>> "James" == James C McPherson
<james.mcpherson(a)optusnet.com.au> writes:
James> Ok, I've attached 3 show-memory-usage outputs. One from
James> startup, one from 8 hours later, and one from 25 hours. I
James> haven't been using xemacs in this time, merely leaving it
James> running.
I'll look at it more carefully later, but I don't see anything there
that would account for the ballooning up that you report. Does this
instance show increased memory usage according the OS (eg, according
to ps)? I think the statistics for Lisp objects are pretty good, so
if you're seeing ballooning up here, it's not GC as such, but
something in a different subsystem (images, fonts, ...).
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
8:29 p.m.
Malcolm Purvis wrote:
>>>>>"James" == James C McPherson
<james.mcpherson(a)optusnet.com.au> writes:
James> Hi all, found a slight problem tonight -- seems to be a gc-related
James> memory leak in 21.5.b16
I've been trying to replicate this but haven't has much success so I 'm
trying
to work out what's missing.
Does this occur is you use xemacs -vanilla?
Do you run any lisp code that runs things every now and then (gnus daemons,
timers, etc)?
Hi all,
haven't had a chance to try to replicate this one yet -
work has been busy so no chance for coding.
I don't know whether -vanilla helps, and as far as I
am aware I am not running anything except gnuserv which
runs with timers or whatever.
Here's what I was doing:
load up a jsp I'm working on
turn this buffer to xml-mode
C x 5 2 and startup a shell (my login shell is /bin/ksh)
. ~/.profile
leave it overnight (7 or so hours)
come in in the morning and check the memory usage -- large.
ciao,
James
7601
days inactive
7617
days old
11 comments
4 participants
participants (4)
-
James C. McPherson -
Malcolm Purvis -
Mats Larsson -
Stephen J. Turnbull