Autoreboot Issues - Areas

Posted by Samryn on Thu 04 Oct 2007 12:17 AM — 7 posts, 22,591 views.

United Kingdom #0
So, lately the mud will not allow the mud to reboot. This happens when the mud is trying to close the mud down I believe... After doing a wee little search using gdb. But now I'm stumped... clueless etc.


(gdb) bt
#0  0x005fc7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0063d7a5 in raise () from /lib/tls/libc.so.6
#2  0x0063f209 in abort () from /lib/tls/libc.so.6
#3  0x00671a1a in __libc_message () from /lib/tls/libc.so.6
#4  0x006782bf in _int_free () from /lib/tls/libc.so.6
#5  0x0067863a in free () from /lib/tls/libc.so.6
#6  0x080ad16c in close_area (pArea=0x99c8210) at act_wiz.c:5571
#7  0x080ad1cb in close_all_areas () at act_wiz.c:5586
#8  0x080e9fd6 in cleanup_memory () at comm.c:334
#9  0x080ea6cd in main (argc=1, argv=0xbfe33924) at comm.c:578



(gdb) frame 1
#1  0x0063d7a5 in raise () from /lib/tls/libc.so.6
(gdb) frame 2
#2  0x0063f209 in abort () from /lib/tls/libc.so.6
(gdb) frame 3
#3  0x00671a1a in __libc_message () from /lib/tls/libc.so.6
(gdb) frame 4
#4  0x006782bf in _int_free () from /lib/tls/libc.so.6
(gdb) frame 5
#5  0x0067863a in free () from /lib/tls/libc.so.6
(gdb) frame 6
#6  0x080ad16c in close_area (pArea=0x99c8210) at act_wiz.c:5571
5571       DISPOSE( pArea );
(gdb) frame 7
#7  0x080ad1cb in close_all_areas () at act_wiz.c:5586
5586          close_area( area );
(gdb) frame 8
#8  0x080e9fd6 in cleanup_memory () at comm.c:334
334        close_all_areas(  );
#9  0x080ea6cd in main (argc=1, argv=0xbfe33924) at comm.c:578
578        cleanup_memory(  );


Any help would be greatful, thanks.
USA #1
It shouldn't prevent the MUD from rebooting. The startup script handles that, so even if it crashes it should boot back up.
United Kingdom #2
The mud has worked for a while, and then suddenly it stopped. Now im wondering it an area being currupted could cause this?

The startup script hasn't been altered anyway, but i'll paste it here and see if you can see anything I cant? Cheers Zeno.


#! /bin/csh -f

# Set the port number.
set port = 6767
if ( "$1" != "" ) set port="$1"

# Change to area directory.
cd ../area

# Set limits.
nohup
nice
limit stack 1024k
if ( -e shutdown.txt ) rm -f shutdown.txt

while ( 1 )
    # If you want to have logs in a different directory,
    #   change the 'set logfile' line to reflect the directory name.
    set index = 1000
    while ( 1 )
        set logfile = ../log/$index.log
        if ( ! -e $logfile ) break
        @ index++
    end

    # Record starting time
    date > $logfile
    date > ../area/boot.txt

    # Record initial charges
    # charges >> $logfile

    # Run SMAUG.
    ../src/smaug $port >&! $logfile
#    ../src/smaug >>&! $logfile

    # Record ending charges
    # charges >> $logfile

#    # Delete this out if no adb.
#    if ( -e core ) then
#           echo '$c' | adb ../src/smaug
#    endif

    # Restart, giving old connections a chance to die.
    if ( -e shutdown.txt ) then
        rm -f shutdown.txt
        exit 0
    endif
    sleep 15
end
USA #3
When the MUD crashes, what is the status of the startup script? Is it still running? It should be.
United Kingdom #4
Apparantly so... but when I logout of the shell, it seems like the startup script stops. If im still logged into the shell it keeps the startup script working...
USA #5
Try running it like this:
nohup ./startup &


As for the crash, I'm not really sure. I don't use cleanup_memory. I think you could safely comment that out..?
USA #6
Commenting it out is just hiding from the problem, I'm not sure you want to do that because the crash is symptomatic of a bigger problem.

It appears that something in cleanup is trying to free memory that has already been freed (that is a very common reason for a program to crash upon a 'free' call). It could also be that, somehow, the pointer got corrupted. The best way to find these is to run your program through valgrind, a memory checking tools; these forums have several references to that so I'd recommend a search for it.