[karajorma]

That would help with getting an exact handle on how to reproduce the error (and it would be very useful) but in the end I need to reproduce it myself using two PCs much of the time. When something goes wrong on the client the question often quickly becomes "Incorrect handling of data on the clients? Or bad data from the server?"

[mjn.mixael]

True, but it'd definitely help to have some multi guys doing with the multi bugs what I've been doing with the single player bugs.

[pecenipicek]

educating people on how to use debug, pdb builds and visual c++ 's debugger would be a good idea too, methinks. or gdb, for the masochists of us on linux/osx

[niffiwan]

gdb is pretty simple, in order to get a stack trace from a FSO crash, do the following in a terminal:

1) install subversion and checkout a current copy of the code

2) install gdb

Code: (Debian/Ubuntu & derivatives) [Select]

sudo apt-get install gdb


Code: (Fedora & friends) [Select]

sudo yum install gdb

3) setup your mod & settings using wxLauncher - in addition to your normal settings you must have:

• a smaller-than-your-entire-monitor resolution (Basic Settings)
• "run in a window" (Advanced Settings -> Dev Tool)
• "don't grab mouse/keyboard in a window" (Advanced Settings -> Dev Tool)

If you don't set these three options, then you'll find that you can't leave the FSO window in order to use the debugger.

4) Run the debug version of FSO (if you don't already have it, pass "--enable-debug" as a parameter to autogen.sh and then compile it)

Code: [Select]

gdb fs2_open_3.6.15_DEBUG

5) gdb has it's own prompt.  Run FSO with this obvious command

Code: [Select]

run
6) Switch to your FSO window and do whatever is necessary to reproduce the crash

7) When the crash has occurred, switch back to your terminal and enter this at the gdb prompt:

Code: [Select]

backtrace
8) copy this output and post it where an SCP member can see it

9) Exit FSO by running this at the gdb prompt:

Code: [Select]

quit

The procedure above is probably all you need. However, if you're interested, here's some more info:

Backtraces
A backtrace (MSVC calls it a stack trace) displays all the function calls that the program has passed through to get to its current position.  Here's an example:

Code: [Select]

(gdb) backtrace
#0  wing_name_lookup (name=0x1993500 "Gamma", ignore_count=1) at ship/ship.cpp:11316
#1  0x00000000005d7dc4 in post_process_mission () at mission/missionparse.cpp:5317
#2  0x00000000005d7b37 in parse_mission (pm=0xfb8120, flags=0) at mission/missionparse.cpp:5270
#3  0x00000000005d8be9 in parse_main (mission_name=0x7fffffffded0 "respawn_crash.fs2", flags=0) at mission/missionparse.cpp:5642
#4  0x00000000005bfd9f in mission_load (filename_ext=0xbfb9c0 "respawn_crash") at mission/missionload.cpp:107
#5  0x000000000040c465 in game_start_mission () at freespace2/freespace.cpp:1450
#6  0x0000000000415e4f in game_enter_state (old_state=20, new_state=52) at freespace2/freespace.cpp:5974
#7  0x00000000004b90fc in gameseq_set_state (new_state=52, override=0) at gamesequence/gamesequence.cpp:282
#8  0x0000000000414ccd in game_process_event (current_state=20, event=1) at freespace2/freespace.cpp:5145
#9  0x00000000004b95f2 in gameseq_process_events () at gamesequence/gamesequence.cpp:397
#10 0x0000000000417605 in game_main (cmdline=0x227edd0 "") at freespace2/freespace.cpp:7092
#11 0x00000000004177da in main (argc=1, argv=0x7fffffffe308) at freespace2/freespace.cpp:7226
(gdb)
The backtrace shows all the function names and the values of variables passed to those functions, e.g. on line 6 above (game_enter_state), you can see that variable old_state was 20, and variable new_state was 52.

Viewing variables
You can view the current value of variables using the gdb print command e.g.

Code: [Select]

print Ship_info[0].name
This can also be used to display nearly any C/C++ expression.

Breakpoints
Breakpoints are a way of stopping FSO from running at a certain point in the code. Set one by entering the following at the gdb prompt:

Code: [Select]

break freespace2/freespace.cpp:1758
The format is directory/filename:line-number (obviously the source code you're getting the file & line number from must match the executable your running, otherwise this information may not match)

Debugging with an FSO release executable
In the rare occasion when you cannot reproduce the crash in FSO debug you can also get a backtrace from the release version.  Use the same procedure as above, but keep in mind these caveats:
1) you must recompile the executable with the gcc -g option set (i.e. CXXFLAGS=-g make)
2) debugging may not be 100% reliable because the release version uses various compiler optimistaions (i.e. gcc -O2)

To workaround both these issues, compile like this and run gdb with the resulting executable:

Code: [Select]

make distclean && CXXFLAGS='-g -O0' sh autogen.sh && V=1 make

(The V=1 is not strictly neccessary, but it does show you if the CXXFLAGS were picked up correctly)

Debugging with a GUI
The command line is all well and good, but sometimes a GUI really helps and ddd is what I've used (the package name should be "ddd" to install with apt-get or yum).  It's very similar to gdb (and in fact, runs gdb underneath) but you get two obvious extras, a window to display variables/data at all times, and an interactive display of the source code (where, among other things, you can set break points via right-clicking on the appropriate line of code).



e: updated & expanded debugging details

[X3N0-Life-Form]

*debugging using gdb*

educating people on how to use debug, pdb builds and visual c++ 's debugger would be a good idea too, methinks. or gdb, for the masochists of us on linux/osx

Time to add a "how to debug" section to the master sticky? It would certainly be useful for newbie coders, and possibly testers as well.

[The E]

You mean, like this?

[Iss Mneur]

Yeah but that is for Visual Studio only.

[The E]

Yes, well, maybe someone who knows how to do the debug dance on Linux and MacOS should update it at some point.

[FreeSpaceFreak]

Yes, well, maybe someone who knows how to do the debug dance on Linux and MacOS should update it at some point.

Yes please

[jg18]

Thoughts off the top of my head on an OS X version (and maybe this conversation should get split and moved to Cross-Platform):

- The most fool-resistant instructions would probably use the dreaded Terminal since you can just copy/paste the commands one-by-one, although people might not be too keen on entering commands they just saw on a forum. At least the Xcode command line tools include SVN.

- The instructions might have to branch at some point for Xcode 3 (for 10.6 and earlier) vs. Xcode 4 (for 10.7+), although I'm hoping that the command line commands are the same (I've never used 4).

- If Xcode doesn't come on the install DVD (do Macs still come with install DVDs?), then people will have to download it, and it's a big download (over 3 GB IIRC) not to mention that you have to register for a free Apple Dev account to get it. The installed Xcode suite is at least 9 GB, and I don't know of a lightweight version that uses less space, although unchecking some options in the Xcode installer might help.

- In short, only the most committed player might be willing to do all that.


EDIT: BTW, looks like the download link for VS2010 Express in the "master sticky" post is broken. It goes to the VS2012 pages instead.

[chief1983]

The score build commands are the same, I've already made xcode4 builds on command line using it.  And you don't need a Dev account to install it via the osx app store now, I believe.  But it is a multi gigabyte download, but so is visual studio

[jg18]

Yeah, sounds right about the App Store, although I think that only Xcode 4 is available through that. And I didn't think VS Express downloads were as big as 3+ GB, although I've never downloaded VS Express before.

The instructions may also have to branch (Xcode 3 vs. 4) for covering how to use the Xcode installer, although maybe default install options are good enough, even if it means people will end up installing a bunch of stuff they'll never use.

[niffiwan]

I've updated my previous post on gdb debugging and also put it in the "Read Me 1st" thread - maybe a mod/admin could be so good as to update the index post?  Thanks!

[The E]

Done.

[FreeSpaceFreak]

I've updated my previous post on gdb debugging and also put it in the "Read Me 1st" thread - maybe a mod/admin could be so good as to update the index post?  Thanks!

[chief1983]

And, we're off.

[jg18]

We are? I thought the code freeze didn't thaw until after the next release, 3.7.

[chief1983]

Well, then clearly we need a new thread, because this one's subject is no longer accurate

I wasn't saying the code freeze is off, FYI, just that 3.6.16 is off.

[Goober5000]

That could probably have been worded better.   In that case, "And we're off" should be interpreted as in a horse or foot race, not as in "The code freeze is off".

To reiterate the clarification, the code freeze remains in effect until after the current Antipodes branch is merged.  That merge will conclude with the release of 3.7.0.

EDIT: See also the first post in the thread...

TLDR: A code freeze is currently in effect.  No new features will be added until after 3.7 is released.

[jg18]

Yes, I understood all that, which is why the post was strange. I didn't pay much attention to the thread title other than "code freeze" anyway.

No need to make a new thread, though. Just change the OP title and we can keep things going.