Emacs crashing after memory upgrade

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Emacs is running on my QNX6 computer has been solid for two months.
However, it does take up a lot of memory, so we added a new 128MB
to the computer, doubling its memory. The computer works fine and
sees the memory. Emacs works fine for editing, but if I run a
compilation, it crashes a short while later with a segmentation
violation. If I compile from the command line, all is OK. Using
gdb on the core, I find that the crash is not always in exactly the
same spot. A sample GDB trace is shown at the end.

Can anyone suggest why this might be? Obviously,the memory is suspect,
but the problem did not appear immediately after the memory was added,
only after a few days. And the system in general is working well.
Why should Emacs be affected?

Thanks in advance
William Morris


Sample core dump. Also seen crashed in SignalKill()

GNU gdb 5.0 (UI_OUT)
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for
details.
This GDB was configured as “–host=x86-pc-nto-qnx --target=ntox86”…(no
debugging symbols found)…
Program terminated with signal 11, segmentation violation.
Reading symbols from /usr/X11R6/lib/libXaw.so.7…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libXmu.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libXt.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libSM.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libICE.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libXext.so.6…(no debugging symbols
found)…done.
Reading symbols from /x86/usr/lib/libtiff.so.3…done.
Reading symbols from /x86/usr/lib/libjpeg.so.2…done.
Reading symbols from /x86/usr/lib/libpng10.so.0…done.
Reading symbols from /x86/usr/lib/libz.so.2…done.
Reading symbols from /x86/lib/libm.so.2…done.
Reading symbols from /usr/X11R6/lib/libXpm.so.4…done.
Reading symbols from /usr/X11R6/lib/libX11.so.6…done.
Reading symbols from /x86/lib/libsocket.so.2…done.
Reading symbols from /x86/lib/libc.so.2…done.
#0 0xb033b1ed in memcpy () from /x86/lib/libc.so.2
(gdb) q

2

Sorry, my gdb info was not so useful. The stack trace is odd in that
it is 807 levels deep, most of which are in main():

(gdb) where
#0 0xb033b1ed in memcpy () from /x86/lib/libc.so.2
#1 0xb0334050 in fwrite () from /x86/lib/libc.so.2
#2 0x080fa53a in main ()
#3 0x080cfbfe in main ()
#4 0x080ce68d in _btext ()
#5 0xb0314512 in __signalstub () from /x86/lib/libc.so.2
#6 0x08112f99 in main ()
#7 0x08112fd1 in main ()
#8 0x0811313d in main ()
#9 0x0811313d in main ()
… etc
#764 0x08124a31 in main ()
#765 0x080c62fe in _btext ()
#766 0x080c6986 in _btext ()
#767 0x08124e19 in main ()
… etc
#796 0x0814fbb6 in main ()
#797 0x08056781 in _btext ()
#798 0x080d2858 in main ()
… etc
#806 0x080d0748 in main ()
#807 0x080cf6da in main ()
(gdb) q

The entries cut out were all “in main ()” but had varying
addresses, often duplicates. Looks like recursion, but in main()?

Regards
William Morris wrote:

Emacs is running on my QNX6 computer has been solid for two months.
However, it does take up a lot of memory, so we added a new 128MB
to the computer, doubling its memory. The computer works fine and
sees the memory. Emacs works fine for editing, but if I run a
compilation, it crashes a short while later with a segmentation
violation. If I compile from the command line, all is OK. Using
gdb on the core, I find that the crash is not always in exactly the
same spot. A sample GDB trace is shown at the end.

Can anyone suggest why this might be? Obviously,the memory is suspect,
but the problem did not appear immediately after the memory was added,
only after a few days. And the system in general is working well.
Why should Emacs be affected?

Thanks in advance
William Morris

Sample core dump. Also seen crashed in SignalKill()

GNU gdb 5.0 (UI_OUT)
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for
details.
This GDB was configured as “–host=x86-pc-nto-qnx --target=ntox86”…(no
debugging symbols found)…
Program terminated with signal 11, segmentation violation.
Reading symbols from /usr/X11R6/lib/libXaw.so.7…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libXmu.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libXt.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libSM.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libICE.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libXext.so.6…(no debugging symbols
found)…done.
Reading symbols from /x86/usr/lib/libtiff.so.3…done.
Reading symbols from /x86/usr/lib/libjpeg.so.2…done.
Reading symbols from /x86/usr/lib/libpng10.so.0…done.
Reading symbols from /x86/usr/lib/libz.so.2…done.
Reading symbols from /x86/lib/libm.so.2…done.
Reading symbols from /usr/X11R6/lib/libXpm.so.4…done.
Reading symbols from /usr/X11R6/lib/libX11.so.6…done.
Reading symbols from /x86/lib/libsocket.so.2…done.
Reading symbols from /x86/lib/libc.so.2…done.
#0 0xb033b1ed in memcpy () from /x86/lib/libc.so.2
(gdb) q

3

I’ve seen this kind of gdb output. Usually this is because you are NOT
compiling with -O0 -g,
so all the “static” funciton name is not in the symbal table, they all
referenced as an offset of
the nearest global function.

Re-compile the file contain main() with -g, you will see.

Also, since the crash point is somebody calling fwrite(). Maybe you can just
grep the source
and lucky enough to find where it is ?

-xtang

William Morris <william@bangel.demon.co.uk> wrote in message
news:3DEC7FD0.432C6585@bangel.demon.co.uk…

Sorry, my gdb info was not so useful. The stack trace is odd in that
it is 807 levels deep, most of which are in main():

(gdb) where
#0 0xb033b1ed in memcpy () from /x86/lib/libc.so.2
#1 0xb0334050 in fwrite () from /x86/lib/libc.so.2
#2 0x080fa53a in main ()
#3 0x080cfbfe in main ()
#4 0x080ce68d in _btext ()
#5 0xb0314512 in __signalstub () from /x86/lib/libc.so.2
#6 0x08112f99 in main ()
#7 0x08112fd1 in main ()
#8 0x0811313d in main ()
#9 0x0811313d in main ()
… etc
#764 0x08124a31 in main ()
#765 0x080c62fe in _btext ()
#766 0x080c6986 in _btext ()
#767 0x08124e19 in main ()
… etc
#796 0x0814fbb6 in main ()
#797 0x08056781 in _btext ()
#798 0x080d2858 in main ()
… etc
#806 0x080d0748 in main ()
#807 0x080cf6da in main ()
(gdb) q

The entries cut out were all “in main ()” but had varying
addresses, often duplicates. Looks like recursion, but in main()?

Regards
William Morris wrote:

Emacs is running on my QNX6 computer has been solid for two months.
However, it does take up a lot of memory, so we added a new 128MB
to the computer, doubling its memory. The computer works fine and
sees the memory. Emacs works fine for editing, but if I run a
compilation, it crashes a short while later with a segmentation
violation. If I compile from the command line, all is OK. Using
gdb on the core, I find that the crash is not always in exactly the
same spot. A sample GDB trace is shown at the end.

Can anyone suggest why this might be? Obviously,the memory is suspect,
but the problem did not appear immediately after the memory was added,
only after a few days. And the system in general is working well.
Why should Emacs be affected?

Thanks in advance
William Morris

Sample core dump. Also seen crashed in SignalKill()

GNU gdb 5.0 (UI_OUT)
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for
details.
This GDB was configured as “–host=x86-pc-nto-qnx --target=ntox86”…(no
debugging symbols found)…
Program terminated with signal 11, segmentation violation.
Reading symbols from /usr/X11R6/lib/libXaw.so.7…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libXmu.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libXt.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libSM.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libICE.so.6…(no debugging symbols
found)…done.
Reading symbols from /usr/X11R6/lib/libXext.so.6…(no debugging symbols
found)…done.
Reading symbols from /x86/usr/lib/libtiff.so.3…done.
Reading symbols from /x86/usr/lib/libjpeg.so.2…done.
Reading symbols from /x86/usr/lib/libpng10.so.0…done.
Reading symbols from /x86/usr/lib/libz.so.2…done.
Reading symbols from /x86/lib/libm.so.2…done.
Reading symbols from /usr/X11R6/lib/libXpm.so.4…done.
Reading symbols from /usr/X11R6/lib/libX11.so.6…done.
Reading symbols from /x86/lib/libsocket.so.2…done.
Reading symbols from /x86/lib/libc.so.2…done.
#0 0xb033b1ed in memcpy () from /x86/lib/libc.so.2
(gdb) q

4

Note that this is not a memory problem per-se. I just rebooted the
server; I then fixed the various corrupted filesystem files such as
syslog, Samba locks and logs and rebooted again. Emacs now runs
compilations fine. So might something in QNX be at fault?