Infinte Recursion

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.

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.

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.

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.

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.

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.

What do you mean you have to leave it up? You can stop gdb at any point by hitting ctrl+c I believe.

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 :(

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

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.

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.

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.