Pinpointing segfaults.

Started by
7 comments, last by ToohrVyk 16 years, 11 months ago
Right now I'm brainstorming for a multiplayer online game. The game being programmed in C++, segfaults are a very real problem. On my last game, I would isolate the crash by using the caption bar. something like this:

while( stuff )
{
SDL_WM_SetCaption( "Doing events", NULL );
events();

SDL_WM_SetCaption( "Doing logic", NULL );
logic();

SDL_WM_SetCaption( "Doing rendering", NULL );
render();
}

and if the last caption update said "Doing events", that meant the crash was in the events module. Then I'd go in the events module and try to locate, and fix the problem. This was years ago so you'll have to excuse the crudeness of this tactic. Well now I'm trying to develop a new method. Running the program through a debugger not a practical option. I don't have a LAN at home and I'll end up having to use a nearby cyber cafe and they're not going to allow me to install IDEs on their PCs. Anybody have any method for pinpointing segfaults? I was thinking of writing to a file to log the game loop, but I can't a mechanism in fstream to clear the contents of the file other than closing then opening and overwriting it.

Learn to make games with my SDL 2 Tutorials

Advertisement
Add your own logger class? and just log everywhere like you did with the SDL_Caption thing
so your log file will show when the program stopped.
First part is you can either 'append' to the log. ios::ate i think to just keep the log persistant.
Or you can do like you said, always open for write (thus killing the log out every run)
Or you can always use something like remove() to delete the log when you are done.

Secondly, remember to flush after every write, or a crash will leave you without some log info.
Thirdly, fun formats are nice, but pick something resilient like HTML(ie a crash and thus lack of
closing tags doesnt affect the ability to view the log). Plain text is always an option, but i like formating in my logger.



But my question is why can't you just run it through a debugger? that often stops it right on the line
of the crash, so you know where part of the error is right off the bat. (plus all the extra information
like the call stack that you can use if the segfault is deep down, and really just a result of your real
error somewhere along a specific call route.)
(i personally dont think that you need internet to program, so no reason you can't just do
this on your home computer)
Quote:Original post by KulSeran
But my question is why can't you just run it through a debugger?


I'm a broke college student, not a game company with thousands to spend on testing equipment. The LAN by my college is the only viable option and I can't install anything on their computers, hell they're kind of iffy about allowing me to test my game on their network.

Learn to make games with my SDL 2 Tutorials

What school computers are you using? windows or linux ones? cauze linux comes with tones of tools to program/debug.
and would really think that they would have VisualStudio if they have a CS department.

If not, wow that sucks. There are IDE's like CodeBlocks that you should be able to get to run off
a pendrive, so you dont have to install anything on their computers to get it to run.

Quote:
I'm a broke college student, not a game company with thousands to spend on testing equipment.

You really dont need thousands of dollars worth of anything unless you are testing something that far excedes
the capability of one machine. This includes multiplayer stuff, wich can mostly(not entierly) be
tested on a single machine.

--edit:
Yeah, back to the point, sorry to sound confrentational, just my school had tones of programming
tools on their machines, and you could remotly use them if you were someplace with internet access(linux side anyway)

but search the boards here, tones of people have writen a lot about differnt loggers and
the like that you could put together for your own system
Like here

--edit again:
dont know about the policy there, but you can also consider many a flavor of linux that you could use to
just hot-boot the machine, so you dont even have to touch their software. Using either a pen-drive or CD-R to
save your files.
Quote:Original post by KulSeran
There are IDE's like CodeBlocks that you should be able to get to run off
a pendrive, so you dont have to install anything on their computers to get it to run.


I'll definitely look into that. I've played with Code::Blocks before and it's a pretty good IDE.

Learn to make games with my SDL 2 Tutorials

I am certain that your university at least offers a copy of gdb.
Can't you get Visual Studio Express for free these days?
"He took a duck in the face at 250 knots."
Quote:Original post by fsm
Can't you get Visual Studio Express for free these days?


Quote:I don't have a LAN at home and I'll end up having to use a nearby cyber cafe and they're not going to allow me to install IDEs on their PCs.


VSEE Is an IDE, FYI. I doubt it'd play well with a thumb drive.



To the OP: Programming without a debugger is a farce, not actual programming, IMO. Even a command line debugger like GDB is better than nothing at all. Also consider:

1) You can do a lot of your debugging locally even without a LAN -- just run two instances of the same client. You may want to look into a Network Simulator for simulating malformed/lost/reordered packets during your debugging.

2) Your average LAN alone isn't going to test your program's response to said malformed/lost/reordered packets terribly well -- they tend to be high quality links.

3) Consider enslaving a friend, if you have an internet connection. This would be a great way to get feedback about what works and what doesn't in terms of your game mechanics as well.
Quote:Original post by Lazy Foo
Right now I'm brainstorming for a multiplayer online game. The game being programmed in C++, segfaults are a very real problem.


Reduce segfault-prone operations to a few files, and heavily instrument (assert, etc) these files, then heavily test them.

It's been months since I've encountered a segfault in a program that was not found inside the fifty-line "hazardous" file for that program. And it was found while unit-testing said file anyway.

This topic is closed to new replies.

Advertisement