Issue with hotboot in SWRIP

Kinda a wierd issue. I installed a hotboot snippet ported to SWR by Greven, and everything seems to be working fine. Until a point. I use the command hotboot and the hotboot goes through cleanly, but upon having someone save and quit out of the mud I get this:

Mon Sep 13 23:47:58 2004 :: Initializing socket
Mon Sep 13 23:47:58 2004 :: Rise in Power ready on port 3000.
Mon Sep 13 23:47:58 2004 :: Initiating hotboot recovery.
Mon Sep 13 23:47:58 2004 :: Loading player data for: Toy (6K)
Mon Sep 13 23:47:58 2004 :: Loading player data for: Chains (1K)
Mon Sep 13 23:47:58 2004 :: Updating area entry for Chains
Mon Sep 13 23:47:58 2004 :: Hotboot recovery complete.
Mon Sep 13 23:48:04 2004 :: Chains has quit.
accept_new: select: poll: Bad file descriptor

and then crashes, so I looked into the error. It's in Comm.c, void accept_new, lines 402-406.



Any thoughts? Anyone? :)

-Toy

I think that's the message you get when you're trying to poll a socket that isn't open. I'm not sure why that would happen, though. :)

After the hotboot completes, attach gdb to it and quit out your character, see where it crashes, and let us know?

The poll error isn't what is crashing it, but its probably a related issue. I imagine it isn't removing the descriptor for the quit character from the linked list, polling a closed socket, and then trying to access something else in the descriptor_data struct, causing the crash. But I can't figure that out without a gdb backtrace.

DV

Actually, yes, the poll error is what's killing the program:

Look at the log entry:

accept_new: select: poll: Bad file descriptor

Look at where this appears in the code:

So, the select is failing, the perror log is written then immediately thereafter the program quits.

But, the problem is certainly one of polling an invalid descriptor. I'm just not sure why it would have one, if this code has been shown to work elsewhere.

Well, I tried running the swrip with gdb.

This GDB was configured as "i686-pc-cygwin"...
(gdb) break do_hotboot
Breakpoint 1 at 0x53ed80: file hotboot.c, line 552.
(gdb) run
Starting program: /home/KK and Li Li/releasev101rip/area/swrip.exe
Tue Sep 14 14:05:29 2004 :: PID: 2720
Tue Sep 14 14:05:29 2004 :: Booting Database

So it started well... but at the bottom I got this:

Resetting: limbo.are
Resetting: newacad.are
Resetting: space.are
Resetting: omni_complex
Tue Sep 14 14:05:29 2004 :: Initializing socket

Program received signal SIGSEGV, Segmentation fault.
0x7c809f62 in KERNEL32!IsBadWritePtr () from /cygdrive/c/WINDOWS/system32/kernel32.dll

I'm not very good with gdb yet, and I'm gonna play around with it a little bit to see how to attach the gdb after the hotboot. It's sorta odd that I can't turn the code on in gdb, but it runs fine with the .exe file. No errors occur until after the hotboot *shrugs*

-Toy

Gah!! You're on Windows. I simply will not debug copyover on Windows. :-P

But, you simply need to start the mud from cygwin, and then can't you attach gdb to the process id:

gdb [exe location] [process number]

To get the process id, just type "ps":



Here, for instance, I started up two cygwin shells, and in one I started vi (well, vim.) Its process id is 504.

So, you would type something like:

gdb mymud.exe 504

That might work, although I admit that I've never tried it.

OK, I tried doing this:

$ ps
PID PPID PGID WINPID TTY UID STIME COMMAND
3080 1 3080 3080 con 1005 19:52:34 /home/KK and Li Li/releasev101rip/area/
swrip
2464 1 2464 2464 con 1005 20:09:38 /usr/bin/bash
2608 2464 2608 3676 con 1005 20:12:40 /usr/bin/ps


So I tried

gdb swrip.exe 3080

I set the breakpoint for do_hotboot, and when I hit run I got this:

$ gdb swrip.exe 3080
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 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 "i686-pc-cygwin"...
Attaching to program `/home/KK and Li Li/releasev101rip/area/swrip.exe', process 3080
[Switching to thread 3080.0x664]
(gdb) break do_hotboot
Breakpoint 1 at 0x53ed80: file hotboot.c, line 552.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n)

If I hit no, nothing happens, just a program not restarted message. If I hit yes, I got through the entire loadup till the initializing sockets part with the same problem:

Tue Sep 14 14:05:29 2004 :: Initializing socket

Program received signal SIGSEGV, Segmentation fault.
0x7c809f62 in KERNEL32!IsBadWritePtr () from /cygdrive/c/WINDOWS/system32/kernel32.dll

I'm stumped as to what to do next.
-Toy

Oh, hey I just found this after I quit outta the gdb and looked in the area directory and found this, gdb.exe:

Exception: STATUS_ACCESS_VIOLATION at eip=0042454C
eax=00000001 ebx=00000000 ecx=7C809F8A edx=00000000 esi=00000000 edi=1012ECF8
ebp=0022E6D8 esp=0022E6B0 program=C:\cygwin\bin\gdb.exe, pid 2644, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
0022E6D8 0042454C (00000000, 1012ECF8, 0022E818, 00422B64)
0022E6E8 00422CA1 (10129CD8, 0022E850, 0022E7F4, 00000400)
0022E818 00422B64 (00422C90, 10129CD8, 0022E850, 0022E848)
0022E858 00422CFA (004244F0, 00000000, 004245A8, 00000006)
0022E878 00424607 (00000000, 00000001, 0022E8A8, 00407B6C)
0022E888 00405879 (1012ECF8, 00000000, 00000001, 00000001)
0022E8A8 00407B6C (1012ECF8, 00000000, 00000001, 00000000)
0022E8E8 004230FB (1010029C, 00000001, 0022E918, 005B8594)
0022E918 00484B4B (10100298, 10223588, 0022E940, 005C852C)
0022E958 00484FC5 (103B6B10, 103B6B10, 0022F140, 103B6B10)
0022E978 005C6ED5 (0022E938, 101234F8, 0022E998, 004849AD)
0022E988 0048438B (00000000, 0000000C, 0022E9B8, 0049D35E)
0022E998 004849AD (00000000, 00000000, 00000000, 0042EFF9)
0022E9B8 0049D35E (00000000, 00000000, 00000000, 00000000)
0022E9D8 0049CD29 (00000000, 0022EE20, 0022E9F8, 00422CA1)
0022E9E8 0049CD88 (00000000, 0022EE20, 0022EB28, 00422B64)
End of stack trace (more stack frames may be present)

Dunno if it's relevant or not. Not sure how these work yet.

-Toy

Those are Windows core dumps, they're basically useless.

You want to type in "continue", not "run" - continue means "keep on going till you hit a breakpoint or crash".

Well, I'm glad I've spent the past 3 years working on altering a stock SMAUG download. Earlier I attempted to edit omni_complex by using rdelete on one of the rooms.

rdelete 105

And the mud became what I like to call a SUPER NOVA. I've reinstalled the stock area files, recompiled cleanly, and done everything I can to track down the problem, but no good. .EXE files loads to space.are and crashes. I think I'll stop experimenting with SWRIP and just go back to my old code.

Of course, my next challenge should be fun. Wanna turn stock SMAUG into a level-less system and class system much like SWR.

Thanks for the help anyways everyone.

-Toy

Sorry to hear that about your code. I hope your future endeavours prove more successful, good luck with them. :)

rdelete is extremely buggy, in both SWR and RiP... I've never been able to get it to crash on demand, so I've never been able to debug it. Ah well.

I highly advise you to read Gammon's guide to gdb. Its incredibly helpful, and should get you to a point where you can figure out issues like this.

I don't think SWR's level/class system is what you are looking for if you are looking for levelless... It would be better to design one from scratch...

Especially since SWR is an awful, awful codebase. SWRIP is just a little less awful, according to my totally unbiased opinion.

DV

Well, my stubborness kicked in this morning. So I decided to try something. I ripped the delete_room function outta SWRIP, replaced it with a copy from the smaug I've been working on, fixed the call in mud.h and watched...

Needless to say rdelete works now.

I guess I need to try to recover everything I lost yesturday on this project...

-Toy the Relentless