Spring RTS Engine

I installed spring 0.73b1 on linux (ubuntu 6.06).
Spring regularly crashes, the console reports everytime "segmentation fault", it happens with nanoblobs 0.63, aa 2.21 and xta. It just happens randomly no returning pattern or crashes with one type of unit.

Are these bugs or can this occur with a bad compilation or something like that?

A somewhat related question: What is a segmentation fault, and what generally causes it? I've had them from other linux programs from time to time and I'd like to know where to start looking to fix them.

A segmentation fault means the program tried to access memory that it didn't have access to.

For example it tried to write to a read-only "page" (chunk of memory) or tried to read from a page of another process.

It usually happens because of uninitialized variables, particularly pointers, writing outside array bounds, or using NULL pointers.

To fix a segmentation fault the most important thing is to be able to reproduce it, preferably as easy as possible. Then you'd usually (re)compile the sourcecode of the program with debugging enabled so you can run it inside the debugger (gdb). Then if you get the segmentation fault again while running in debugger, you can create a stacktrace and look at that place in the source.

If you're lucky the bug is pretty obvious but usually only then the detective work starts to figure out why that certain pointer was uninitialized, why it was NULL, etc. A good knowledge of the language the program is written in definitely helps in that case, but the developers will be very happy already if you can supply them with a unambiguous instructions "how to reproduce" the bug, the stacktrace, and any data files needed to reproduce it.

Also make sure to only debug the recentmost version of a program, preferably a version from CVS/SVN/bazaar/etc. otherwise you might be spilling your time if the bug has already been fixed upstream.

I'd like to try to reproduce the segmentation fault, but how do i recompile spring with debugging enabled?

And gdb would work like "gdb ./spring" right? because i am not going to read all this: http://sources.redhat.com/gdb/current/o ... b_toc.html

Ultraquick debugging on linux help
Compiling spring Running spring in gdb and making a backtrace after it crashes

Thanks Tobi, I will keep that in mind if I have those issues again.

Thanks, i made a backtrace but it looks absurdly long. Another question were does it save the backtrace? And will i have to paste it in pastebin or something like that?

Put it anywhere, be it pastebin, rapidshare, filefront, spring issue tracker, whatever. The sooner, the better :)

architeuthis wrote:Thanks, i made a backtrace but it looks absurdly long. Another question were does it save the backtrace? And will i have to paste it in pastebin or something like that?

The backtrace isn't saved, you should just copy paste it. A pastebin is fine yeah.

Ok here is it:
The enitire bt is more then 20000 lines long, i hope this is what you need?
Do you need more info (map, mod etc)?

I got another one, this one is pracitcally the same:
Are these the same or is this just the same bug but on another moment?

Hm I fear it's maybe an ATI driver bug seeing that first stackframe, but feel free to post the entire backtrace. If it's that long put it on a pastebin or some public file server thing and give a link to it here.

The backtrace is extremly long (+2000 lines), i have to press enter to continue every 20 lines, and my console remembers only 100 lines, so i have to copy them seperatly and i really dont have the time to copy thousands of lines. But i came this far: http://pastebin.com/802452

If its a driver issue, i have a big problem, ati stopped supporting my ati9250 pro, damned ati.

I hope i helped you and contributed to spring.

Was my bug report useful or is it really a driver issue? Is someone else maybe experiencing the same problem?

If its a driver issue is there any thing i can do, because ati is no longer making drivers for my ati9250?

It seems really a driver thing. I think I saw identical looking backtraces in other cases.
Maybe if it ends with something different then the bunch of identical lines, it could be useful (that end part that is).

Yep the crash is in a fire gl driver component.

You can try the open drivers, they are slower but dont have such short lifetimes. (r200 series could be too slow for spring with open drivers)

I'm running spring on the open r300 driver (x700 64bit mem) and it's just doable. But svn is crashing there more often for me too, with a lockup of the hardware. It's unlikely it's springs fault though, too many incriminating other factors.

Thanks for the help, i'll chech out those open drivers?

edit: can you tell me which open drivers you use?

architeuthis wrote:The backtrace is extremly long (+2000 lines), i have to press enter to continue every 20 lines, and my console remembers only 100 lines, so i have to copy them seperatly and i really dont have the time to copy thousands of lines.

If the debug information is sent to stdOUT, you could use redirecting...
your +2000 lines file will be located in your home directory then, I suppose

please correct me if I´m wrong


anyway, I´ve an SEGFault as well...
I used Spring for a week or so on Ubuntu Feisty and suddenly during a AiSkirmish Spring segfaulted. Since then neither the Ubuntu .deb-packet nor the self-compiled version would run...

Necro post! Sorcery I say!

oh, sry, i´ll start a new thread...