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
➜ Infinte Recursion
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Atrox
USA (18 posts) Bio
|
| Date
| Thu 29 Apr 2004 03:17 AM (UTC) |
| Message
| For some reason my mud is getting stuck in an infinte loop and just hogging down the cpu. I can only assume that it's recursion gone wrong, but as far as I know, the only recursion I'm using is in the timers for skills. I would hope that DO_FUN timers work properly, but you never know. If anyone else has had any problems with DO_FUN timers, let me know.
Other than that, does anyone know how to actually figure out where it's getting stuck in the loop? When it gets caught, I can't make it generate a core file (or I don't know how) so I can't very well see the line that started it, or what function it's in to try and backtrace. | | Top |
|
| Posted by
| Zeno
USA (2,871 posts) Bio
|
| Date
| Reply #1 on Thu 29 Apr 2004 03:39 AM (UTC) |
| Message
| | When it gets caught in the loop, or before it does, attach gdb to it. "gdb smaug <PID>". I think thats how its done. Then watch it, and do a backtrace, etc. |
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org | | Top |
|
| Posted by
| Atrox
USA (18 posts) Bio
|
| Date
| Reply #2 on Thu 29 Apr 2004 08:27 PM (UTC) |
| Message
| That would mean I'd have to leave an instance of putty open and useless, I just want to know if there's way to terminate the mud and make it write that to a core file so I could try and see what function it was stuck looping in. I really don't want to attach gdb to the pid, there should be an easier way.
I'm going to try and send a SIGSEG message to the mud with the kill command, that should work. I'll post a note if I figure it out. | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #3 on Thu 29 Apr 2004 09:19 PM (UTC) |
| Message
| | What's so evil about attaching gdb to a process id? That's kind of what debugging is all about! :) Seems to me that sending segfault signals is more complicated than just turning on gdb. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Atrox
USA (18 posts) Bio
|
| Date
| Reply #4 on Thu 29 Apr 2004 11:09 PM (UTC) |
| Message
| Yea, but I just hate having a window open that I'm not using, I'm a bitch about screen real estate. Anyway, sending the segfault worked fine. kill -SIGSEGV <pid>
Although, it only said that it was in the game_loop, which can't possibly be the problem... so now I'm lost :(
Oh yea, I remember why I didn't want to attach gdb to it, because, it's not crashing, it's getting stuck in a recursive loop (one function calling itself over and over with no exit condition), at least I think it's a recursive loop. Could just be a while loop with no exit. Either way, I'm having a hard time finding it. | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #5 on Thu 29 Apr 2004 11:21 PM (UTC) |
| Message
| You don't need to leave the window open when you're not using it, I'm not sure what your problem is there.
When it goes into the loop, that's when you'd attach GDB to it. That'll show you exactly where it's looping.
I wouldn't make assumptions about recursive loops. I would wait until it stops responding and then attach GDB and see what's going on. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Nick Cash
USA (626 posts) Bio
|
| Date
| Reply #6 on Fri 30 Apr 2004 01:29 AM (UTC) |
| Message
| | What do you mean you have to leave it up? You can stop gdb at any point by hitting ctrl+c I believe. |
~Nick Cash
http://www.nick-cash.com | | Top |
|
| Posted by
| Atrox
USA (18 posts) Bio
|
| Date
| Reply #7 on Fri 30 Apr 2004 02:05 AM (UTC) |
| Message
| | I don't think you can, but even so, if I wanted to get any kind of use out of it I'd have to leave it running until the mud hit a snag. I'd rather just backtrace my core files. However, I still can't figure out where the mud is getting caught in the loop :( | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #8 on Fri 30 Apr 2004 02:37 AM (UTC) |
| Message
| Of course you can start and stop GDB whenever you feel like it. That's what attaching it to a process id means! The program is running peacefully (or not so peacefully in this case), you attach GDB to it, you see what's going on, then you quit GDB and you leave the process running. No problems.
You can't really just backtrace core files without having a core file generated. How are you going to generate it? When the MUD hits a snag. The MUD can't tell it hit a snag; you can tell when it stops responding. At which point you log on to the server and send a segfault signal... generating a core that you use gdb to look through. Why not just attach gdb directly? It's simpler, you have more information and power than in a core file, etc.
You do *not* have to leave GDB running until the MUD hits a snag. When the MUD hits a snag, *that* is when you attach GDB to it. I have the impression that you want to find out where the MUD is having a problem, but that you don't want to look properly for it!
If you need help with powerful GDB commands such as stepping through a process (which you can't do in a core file, and which can reveal exceedingly important information), Nick wrote an excellent guide to GDB, which you may find here:
http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=3653 |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Atrox
USA (18 posts) Bio
|
| Date
| Reply #9 on Fri 30 Apr 2004 03:32 AM (UTC) |
| Message
| Thx for that link, that's really all I ever wanted to know. I'm used to debugging in Visual Studio, and I was hoping that GDB had the ability to step through functions and code. Also, the problem with it lagging out, was before this guide, I wasn't sure how to make gdb do anything once I attached it to the lagging pid.
Thanks a lot, this should solve SO many problems. | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #10 on Fri 30 Apr 2004 03:42 AM (UTC) |
| Message
| For future reference, next time it would be better to say that you don't know how to use GDB so that we can help you with GDB, instead of saying that GBD can't do what you want it to do. :)
Glad to hear that you're solving the problem. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #11 on Fri 30 Apr 2004 10:15 PM (UTC) |
| Message
|
Quote:
That would mean I'd have to leave an instance of putty open and useless ...
There isn't any difference between starting up a putty window to send SIGTERM to the process than starting up one to attach gdb to the process. In neither case do you need it running beforehand.
Virtually anything you can do with Visual Studio's debugger you can do with gdb, once you get used to it. Since I use Visual Studio a fair bit that is why that post that Ksilyan gave you covers so much stuff.
For instance, the "watch variables automatically" window in Visual Studio is the "display" command in gdb. And, seeing the local variables automatically can be done with a small bit of scripting. It is all in the post. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | 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.
27,558 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top