Re: ThinkPad R51 creeping segmentation faults
Thanks to everyone who read and/or responded to my query. I've got some
additional information that may prompt some additional discussion.
It seems there there is some chance that the problem is due to a RAM
fault. I had run memtest86+ before I made the initial posting and hadn't
gotten any failure indication. More recently I've run a program called
memtester that runs not at boot time, but under linux. It can't test all
memory, but about 90%. linux itself appears to be quite stable on this
machine with no other problems after more than four days of uptime and
quite a bit of activity on the machine. So I'm not that concerned about
the memory that can't be tested as it doesn't seem to be the source the
of the problem. Anyhow, memtester hasn't found any failures at all thus
far.
Running memtester showed that the segmentation fault problem could be
cleared by allocating a large block of memory and then freeing it,
thereby kind of resetting the system heap and minimizing the memory used
for buffers and cached pages. So the problem really isn't that critical
any more, in that if it occurs I can just free up system buffers and
cached pages:
echo 3 | sudo tee /proc/sys/vm/drop_caches
and everything just hums along until some other future time, when said
incantation can just be done again.
I've also run across a system tool called "pmap" that shows the memory
map of an indicated process. As an example here's the memory map of the
"ed" editor. Quite a bit smaller than emacs, ~145M, and vi, ~45M.
pmap 4493
4493: ed
08048000 40K r-x-- /bin/ed
08052000 4K r---- /bin/ed
08053000 4K rw--- /bin/ed
08c86000 132K rw--- [ anon ]
b749f000 1500K r---- /usr/lib/locale/locale-archive
b7616000 4K rw--- [ anon ]
b7617000 1404K r-x-- /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7776000 8K r---- /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7778000 4K rw--- /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7779000 12K rw--- [ anon ]
b7786000 4K rw--- [ anon ]
b7787000 28K r--s- /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache
b778e000 8K rw--- [ anon ]
b7790000 4K r-x-- [ anon ]
b7791000 8K r---- [ anon ]
b7793000 112K r-x-- /lib/i386-linux-gnu/ld-2.13.so
b77af000 4K r---- /lib/i386-linux-gnu/ld-2.13.so
b77b0000 4K rw--- /lib/i386-linux-gnu/ld-2.13.so
bfe04000 132K rw--- [ stack ]
total 3416K
I'm thinking that I can use this tool together with the grub BADRAM
facility, /etc/default/grub, to maybe find and map out failing memory
locations. If anyone has any experience with such things please post any
time saving hints that you may have.
It also turns out that building emacs is not that difficult, with the
proper incantations:
sudo aptitude install dkpg-dev
sudo apt-get build-dep emacs23
cd ~/src/emacs
apt-get source emacs23 --compile
But it also turns out that the resulting emacs binary is not the same as
the installed binary and indeed does not fault when the installed binary
does fault. The sizes of the two different binaries:
-rwxr-xr-x 1 root root 6731016 Sep 9 2012 /usr/bin/emacs23-x
-rwxr-xr-x 1 paula paula 6825224 Jun 16 17:05 emacs23-x
seem to indicate some significant differences. Just for posterity, does
anyone have any insight into how one can build the identical Debian
binary to that installed?
Paul Ausbeck
Reply to: