Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ SMAUG ➜ SMAUG coding ➜ Bug / GDB / Memory Leak
Bug / GDB / Memory Leak

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2 

Posted by Greven   Canada  (835 posts)  Bio
Date Reply #15 on Mon 25 Aug 2003 04:58 AM (UTC)
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
Top
Posted by Boborak   USA  (228 posts)  Bio
Date Reply #16 on Tue 26 Aug 2003 02:35 PM (UTC)
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.
Top
Posted by Samson   USA  (683 posts)  Bio
Date Reply #17 on Wed 27 Aug 2003 03:39 PM (UTC)
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. :)
Top
Posted by Greven   Canada  (835 posts)  Bio
Date Reply #18 on Thu 28 Aug 2003 03:53 PM (UTC)

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
Top
Posted by Boborak   USA  (228 posts)  Bio
Date Reply #19 on Thu 28 Aug 2003 05:16 PM (UTC)
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
Top
Posted by Greven   Canada  (835 posts)  Bio
Date Reply #20 on Thu 28 Aug 2003 05:56 PM (UTC)

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
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #21 on Thu 28 Aug 2003 08:59 PM (UTC)
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
Top
Posted by Greven   Canada  (835 posts)  Bio
Date Reply #22 on Thu 28 Aug 2003 10:13 PM (UTC)

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
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #23 on Fri 29 Aug 2003 12:51 AM (UTC)
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
Top
Posted by Greven   Canada  (835 posts)  Bio
Date Reply #24 on Fri 29 Aug 2003 12:57 AM (UTC)
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
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.

68,751 views.

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

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home