[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  SMAUG
. -> [Folder]  SMAUG coding
. . -> [Subject]  Bug / GDB / Memory Leak
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Bug / GDB / Memory Leak
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please)
Maximum of 6000 characters. Text only please, no HTML.
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  

Posted by Greven   Canada  (835 posts)  [Biography] bio
Date Fri 29 Aug 2003 12:57 AM (UTC)  [ quote  ]
Message
Well, I looked into the code, and load_char_obj actually uses the playerfile and set fpArea as such:

	/* Cheat so that bug will show line #'s -- Altrag */
	fpArea = fp;
	strcpy(strArea, strsave);

So that explains why fpArea is not null when encountering an error while loading a character, but doesn't help me in the slightest in trying to debug it, as I don't understand what the getc() function is doing or why.
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Fri 29 Aug 2003 12:51 AM (UTC)  [ quote  ]
Message
Well, they can't be if it isn't null when the bug is called, unless something else is corrupting it.

OK, put a breakpoint on the lines which you added which sets fpArea to null, and make sure *they* are called.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Greven   Canada  (835 posts)  [Biography] bio
Date Thu 28 Aug 2003 10:13 PM (UTC)  [ quote  ]

Amended on Thu 28 Aug 2003 10:19 PM (UTC) by Greven

Message
Its not crashing, its freezing, but no, fpArea is not null. Whether its valid or not, I don't know, but it is returning a pointer. The only places that fpArea is called from are db.c and save.c, and both are nulling fpArea.
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Thu 28 Aug 2003 08:59 PM (UTC)  [ quote  ]
Message
Put a breakpoint in bug and work out why it is crashing. For instance, if fpArea null or not?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Greven   Canada  (835 posts)  [Biography] bio
Date Thu 28 Aug 2003 05:56 PM (UTC)  [ quote  ]

Amended on Thu 28 Aug 2003 07:37 PM (UTC) by Greven

Message
The problem with the pfiles was that they were only half written due to lack of server space, and would end in something like:

#OBJECT
Vnum         10317
Values       20 0 0 0 0 0
End

#OBJECT
N

The pfile stuff I can fix, I commented out bug(), did a loadup, force them to save, and quit, works nicely.

Problem is that its not logging anything to the log file because its the bug function thats screwed up. That line of code comes from bug(), and the most that my log files have is this:

Wed Aug 27 22:05:17 2003 :: Sock.sinaddr:  198.53.93.106, port 62660.
Wed Aug 27 22:05:18 2003 :: Preloading player data for: Katrina (4K)
Wed Aug 27 22:05:20 2003 :: Loading player data for: Katrina (4K)


And then it stops cause I have to kill it from my shell. If I run it inside gdb, and I cause the freeze when I loadup a bad pfile while bug is not commented out, I pause the game from within gdb and backtrace to get this:

#0  0x2ab681bd in ?? ()
#1  0x2ab680d8 in ?? ()
#2  0x2ab6555e in ?? ()
#3  0x80dcc7e in bug (str=0x81fa560 "fread_word: EOF encountered on read.\n\r") at db.c:3867
#4  0x80dbd64 in fread_word (fp=0x8678b00) at db.c:3335
#5  0x8135973 in fread_obj (ch=0x8677388, fp=0x8678b00, os_type=0) at save.c:1857
#6  0x813161b in load_char_obj (d=0x8675e30, name=0x7fffcfd8 "Katrina", preload=0 '\000') at save.c:956
#7  0x808fe6e in do_loadup (ch=0x8672640, argument=0x7ffff587 "katrina") at act_wiz.c:4406
#8  0x80fa46d in interpret (ch=0x8672640, argument=0x7ffff587 "katrina") at interp.c:354
#9  0x80c645b in game_loop () at comm.c:624
#10 0x80c55b7 in main (argc=2, argv=0x7ffffa04) at comm.c:255
#11 0x2ab2baa7 in ?? ()


Hope that helps, sorry about the vagueness.
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
[Go to top] top
Posted by Boborak   USA  (228 posts)  [Biography] bio
Date Thu 28 Aug 2003 05:16 PM (UTC)  [ quote  ]
Message
Eww. Pfile corruption is no fun, but unfortunately it is likely because of something you may have added. You may have to delete those pfiles to solve the problem or worst yet, the problem may actually be a code issue. Unfortunately it's hard to give guidance without some examples of the bugs you're getting. Posting a single line of code without telling what function or file it's from doesn't help alot ;-) The good news is I know where that particular line comes from and what it does. Bad news is, it really doesn't explain your pfile problem. Need error messages! ;-) Post some of your log here and we'll see what we can do with it.

-Bobo
[Go to top] top
Posted by Greven   Canada  (835 posts)  [Biography] bio
Date Thu 28 Aug 2003 03:53 PM (UTC)  [ quote  ]

Amended on Thu 28 Aug 2003 05:46 PM (UTC) by Greven

Message
Yes, I've nulled the fpArea's, but it seem that I've come along to another problem with bug:


		while ( getc( fpArea ) != '\n' )


I've been away for a couple of days, and my shell account ran out of space due to a massive log file that had alot of wierd stuff spit into it. This caused some of my player's pfiles to become corrupted, so when they load, boom. One had a problem with this .home file, but got that under control, it just crashed. However, another of my players pfile itself got corrupted, and when she would log on, it would freeze, and my host is getting pissed. I commented out bug and loadedup her file and made her save to correct her pfile, but I still have this problem. The above line was frame 6, I got it from gdb it and making it freeze when I did a loadup on here character. Why would this suddenly start to act up now? The server is using the same version of linux that it has since I started with them. I dunno, any help would be great. Also, I gdb init_socket, and it would only come up when I booted, not when I did a copyover, but the extra description would still be there. When I'm setting the break point though, its not grabbing a system function, its grabbing the one in comm.c. Are they much different? I assume they are
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
[Go to top] top
Posted by Samson   USA  (683 posts)  [Biography] bio
Date Wed 27 Aug 2003 03:39 PM (UTC)  [ quote  ]
Message
I couldn't tell if you guys had resolved the fpArea problem yet or not, but just in case you haven't, the solution to that is fairly simple.

Open up db.c, and wherever you see:


fclose( fpArea );


Add:


fpArea = NULL;


This has always been necessary, but since Smaug came about way back in the day and was originally written on Redhat 5/6 it was never an issue back then. Not NULL'ing the file pointer didn't cause issues. When Redhat updated the Glibc libraries somewhere along the way, this became a huge problem and was discussed at length on the SML. Most Smaug derivs have now corrected for this with the above simple fix. Evidently SWR missed the boat on that one. :)
SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top
Posted by Boborak   USA  (228 posts)  [Biography] bio
Date Tue 26 Aug 2003 02:35 PM (UTC)  [ quote  ]
Message
Try setting a break for init_socket it's an OS level function but you can at least do a backtrace for each break to find where the code is being called.
[Go to top] top
Posted by Greven   Canada  (835 posts)  [Biography] bio
Date Mon 25 Aug 2003 04:58 AM (UTC)  [ quote  ]
Message
Hello

I commented out the lines, and I start with three less, but I am still getting an extra one with the copyovers. I'm considering maybe getting a different copyover code, because I would like to solve this problem, but I really don't have that much time anymore, and this might just be quicker. What function starts initializing the sockets? If I need to, I might gdb it, and set a break on the function and check where its being called from.

Thanks,
Greven
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
[Go to top] top
Posted by Boborak   USA  (228 posts)  [Biography] bio
Date Sun 24 Aug 2003 02:58 PM (UTC)  [ quote  ]
Message
Most multi-port smaug setups I have seen, are pretty useless, but aren't exactly a bad thing either. "Extra" sockets are not really a huge resource hog so they don't really hurt much. But if you want to clear up that "extra" socket issue on copyovers, try killing the excess ports to see if that helps.

Find this code:

if (!fCopyOver) /* We have already the port if copyover'ed */
     {
        control = init_socket (port);
        control2 = init_socket( port+1 );
        conclient= init_socket( port+10);
        conjava  = init_socket( port+20); 
     }

Comment out the last three lines, do a hard reboot and then do a copyover and see if you get that extra socket. Hope that helps.

-Bobo
[Go to top] top
Posted by Greven   Canada  (835 posts)  [Biography] bio
Date Sun 24 Aug 2003 02:45 PM (UTC)  [ quote  ]
Message
My main port is 4848, but I can connect to it through 4848, 4849, 4858, and 4868. I tested it through my client to make sure, and it does work that way. I haven't touched any part of that, and I have no idea why it would initialize on 4 seperate ports anyways. Thanks for the help.
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
[Go to top] top
Posted by Boborak   USA  (228 posts)  [Biography] bio
Date Sun 24 Aug 2003 09:26 AM (UTC)  [ quote  ]
Message
Which ports do you actually use for your mud? I have a feeling your mud is set up to run with one port, but the copyover snippet you installed is for a multi-port setup. Stock SWR1.0 is a single-port setup.

-Bobo
[Go to top] top
Posted by Greven   Canada  (835 posts)  [Biography] bio
Date Fri 22 Aug 2003 03:23 PM (UTC)  [ quote  ]

Amended on Fri 22 Aug 2003 03:35 PM (UTC) by Greven

Message
Well, here is what it looks like:


    /*
     * Run the game.
     */

    log_string("Booting Database");
    boot_db(fCopyOver);
    log_string("Initializing socket");
    if (!fCopyOver) /* We have already the port if copyover'ed */
     {
        control = init_socket (port);
        control2 = init_socket( port+1 );
        conclient= init_socket( port+10);
        conjava  = init_socket( port+20); 
     }
    sprintf( log_buf, "Star Wars Reality ready on port %d.", port );                                                                                                                          
    log_string( log_buf );
    game_loop( );
    /*
     * That's all, folks.
     */
    log_string( "Normal termination of game." );
    exit( 0 );
    return 0;


I haven't touched anything in the way of connection sockets, in fact, the only thing I've done in comm.c was add samson's
customizable color code and change the way character creation looks. Otherwise its stock SWR 1.0 . Hope that
makes some sense.

Sorry, I'm using "Swr-Copyover-7" that can be found on
kyndig in the SWR area, its a port of "Erwin's Copyover-7
with some modifications to work on a swr based mud".
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
[Go to top] top
Posted by Boborak   USA  (228 posts)  [Biography] bio
Date Fri 22 Aug 2003 01:29 PM (UTC)  [ quote  ]
Message
Assuming you haven't added any IMC code or anything else that may play with sockets there's only two places I can think of off hand that you should look.

First look in comm.c for the section of code that sets up your mud's port. This is an important piece of code regarding copyover. It should look something like this:


    /*
    * Run the game.
    */
    log_string("Booting Database");
    boot_db(fCopyOver);
    log_string("Initializing socket");
    if (!fCopyOver)
       control = init_socket (port);


If you're missing the "if (!fCopyOver)", then obviously that's part of your problem. A new port should NOT be initalized on copyover. Considering the rest of the copyover code is in place that should fix your problem.

Now if you DO have that if check, then obviously there's something else not kosher ;-) You'll have to give me more specifics about your particular setup.

-Bobo
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

6,565 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]