Vanilla List Maling List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
daemonII crashing on linux
[2nd attempt. List address was wrong before.]
Here are some details about my system:
Machine/OS: pickled.fox.cs.cmu.edu, running redhat linux 4.2
Compiler: gcc 2.8.1
Server: Vanilla 2.9pl2
conifg.h.in: -SHOW_RSA -SB_TRANSWARP -BASEPRACTICE +CLUE2 -DOGFIGHT
+ALLOW_EJECT -AUTO_HOCKEY -TRIPLE_PLANET_MAYHEM
+RANDOM_PRACTICE_ROBOT (these are the changes only)
My pickup server crashes with a segmentation violation sent to
daemonII. It seems to crash only in tmode and only after a few
minutes of play. I have not found a specific action in play which
will cause the crash.
I have NOT been able to get useful information about the crash, either
from core files or by attaching to a running daemon with gdb. I have
yet to try setting the 'debug' flag in daemon and will do that once
this mail is sent.
The machine is running both pl2 pickup and INL servers. The problem
has only occurred on the pickup server. The servers have different
ports and different PKEYs. Moreover, I killed the INL server and
destroyed it's shared memory segment and the pickup server still
crashes.
Below I describe my attempts to find out what code causes the signal.
Between each attempt, I destroyed the shared memory segment and
restarted the server.
Hope this is helpful,
-dave
----
A gdb backtrace of the original core file is not very useful. Text in
the ERRORS file indicates that exitDaemon caught a segmentation
violation. The trace below is consistant with that routine calling
abort() to create a core file.
[netrek@pickled vanilla-2.9pl2]$ gdb --directory=~/src/Vanilla-2.9pl2 daemonII.1 crash/core.1
GDB is free software and you are welcome to 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.
GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation, Inc...
Core was generated by `daemon'.
Program terminated with signal 6, IOT trap/Abort.
Reading symbols from /lib/libm.so.5.0.6...done.
Reading symbols from /lib/libc.so.5.3.12...done.
Reading symbols from /lib/ld-linux.so.1...done.
#0 0x400289e9 in __kill ()
(gdb) bt
#0 0x400289e9 in __kill ()
#1 0x40064775 in gsignal ()
#2 0xbffffac0 in ?? ()
Cannot access memory at address 0xa3234.
(gdb)
----
I tried disabling 'exitDaemon' as the SEGV signal handler, hoping that
the core file would be more informative. I added ``SIGNAL(SIGSEGV,
SIG_DFL);'' after the handlers are set in main(). A gdb backtrace
of this core file is just as useless:
[netrek@pickled vanilla-2.9pl2]$ gdb --directory=~/src/Vanilla-2.9pl2 daemonII.2 crash/core.2
GDB is free software and you are welcome to 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.
GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation, Inc...
Core was generated by `daemon'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.5.0.6...done.
Reading symbols from /lib/libc.so.5.3.12...done.
Reading symbols from /lib/ld-linux.so.1...done.
#0 0x61730a30 in ?? ()
(gdb) bt
#0 0x61730a30 in ?? ()
#1 0x6d20646e in ?? ()
Cannot access memory at address 0xa340a46.
(gdb)
----
I tried attaching to a running daemon in gdb hoping that when the signal
comes, the backtrace would be informative. It wasn't.