Debugging sync errors - Revision history

Abma: /* Using buildbot */

2016-07-26T20:52:10Z

Using buildbot

← Older revision		Revision as of 21:52, 26 July 2016
Line 51:		Line 51:

	If the build works, an executable will be uploaded to the usual place; at the time of this writing, it's http://springrts.com/dl/buildbot/syncdebug/. The generated archive will have [syncdebug] in its name.		If the build works, an executable will be uploaded to the usual place; at the time of this writing, it's http://springrts.com/dl/buildbot/syncdebug/. The generated archive will have [syncdebug] in its name.

			Valid values for config are stored in [https://github.com/spring/spring/blob/develop/buildbot/master/master.cfg#L57 master.cfg] of the buildbot config.

	===Self-Compile===		===Self-Compile===

2016-07-26T20:44:40Z

Compiling

← Older revision		Revision as of 21:44, 26 July 2016
Line 41:		Line 41:

	===Using buildbot===		===Using buildbot===
	Go to http://buildbot.springrts.com/builders/full-windows set		Go to http://buildbot.springrts.com/builders/full-windows-test set

	<code>		<code>

2015-12-14T22:13:31Z

valgrind -> address sanitizer

← Older revision		Revision as of 23:13, 14 December 2015
Line 21:		Line 21:
	</pre></code>		</pre></code>

	==check for memory corruption with ~~valgrind~~==		==check for memory corruption with gcc's address sanitizer==

			compile spring with gcc's address sanitizer (gcc >= 4.8.0)

	~~An first check should be, to run a desynced demo with valgrind with spring-headless:~~
	<code><pre>		<code><pre>
	~~valgrind~~ --~~trace~~-~~children~~=~~yes~~ -~~-log-file~~=~~valgrind.log~~ spring-headless ~~demofile.sdf~~		cmake . -DCMAKE_CXX_FLAGS=-fsanitize=address -DCMAKE_C_FLAGS=-fsanitize=address
			make spring-headless
	</pre></code>		</pre></code>

	~~this maybe prevents you from compiling + running a sync-debugging installation.~~		then run the demo with the compiled spring:

	~~Note: set HangTimeout = 0 to prevent the watchdog printing stacktraces~~.		<code><pre>
			spring-headless demofile.sdf
			</pre></code>

	==Compiling==		==Compiling==

2015-06-24T21:17:06Z

Self-Compile

← Older revision		Revision as of 22:17, 24 June 2015
Line 51:		Line 51:
	To compile it, first get the same revision from git, configure with		To compile it, first get the same revision from git, configure with

	<code><pre>cmake -DCMAKE_BUILD_TYPE=DEBUG -~~DTRACE_SYNC~~=true -~~DSYNCDEBUG~~=true</pre></code>		<code><pre>cmake -DCMAKE_BUILD_TYPE=DEBUG -DSYNCDEBUG=true</pre></code>


			you can add

			<code><pre>-DTRACE_SYNC=true</pre></code>

			which makes spring write a trace file which can be compared with "diff".

	==Running==		==Running==

2015-06-24T21:15:13Z

Self-Compile

← Older revision		Revision as of 22:15, 24 June 2015
Line 51:		Line 51:
	To compile it, first get the same revision from git, configure with		To compile it, first get the same revision from git, configure with

	<code><pre>cmake -DCMAKE_BUILD_TYPE=~~DEBUG2~~ -DTRACE_SYNC=true -DSYNCDEBUG=true</pre></code>		<code><pre>cmake -DCMAKE_BUILD_TYPE=DEBUG -DTRACE_SYNC=true -DSYNCDEBUG=true</pre></code>

	==Running==		==Running==

2015-06-23T05:44:59Z

indent

2015-06-23T05:44:42Z

add "check for NANs"

← Older revision		Revision as of 06:44, 23 June 2015
Line 8:		Line 8:
	First of all, before trying to find a sync-error you should make sure, that running with SIGNAL_NANS=TRUE works without getting SIGFPE's and valgrind doesn't detect invalid reads/writes as this can cause desyncs, too.		First of all, before trying to find a sync-error you should make sure, that running with SIGNAL_NANS=TRUE works without getting SIGFPE's and valgrind doesn't detect invalid reads/writes as this can cause desyncs, too.

			==check for NANs==

			edit CMakeCache.txt and set SIGNAL_NANS=TRUE, recompile spring.

			run spring and ideally, if you have a replay which desynced, run it with the nan-checking spring. else try some stuff like

			<code><pre>
			/cheat
			/give all
			/give all 1
			/give 100 unitname ...
			</pre></code>

	==check for memory corruption with valgrind==		==check for memory corruption with valgrind==

2013-10-26T03:39:49Z

Using buildbot

← Older revision		Revision as of 04:39, 26 October 2013
Line 25:		Line 25:

	===Using buildbot===		===Using buildbot===
	Go to http://springrts.com~~:7778~~/builders/full-windows set		Go to http://buildbot.springrts.com/builders/full-windows set

	<code>		<code>

2013-03-20T19:50:14Z

recat

← Older revision		Revision as of 20:50, 20 March 2013
Line 73:		Line 73:
	All previously required postprocessing has now been built into the sync debugger, so this step is quickly done: just check that syncdebug-server.log looks sane and if it does, send it to the team. You can also make a diff of trace0.log (taken from client + server) to see where the desync started.		All previously required postprocessing has now been built into the sync debugger, so this step is quickly done: just check that syncdebug-server.log looks sane and if it does, send it to the team. You can also make a diff of trace0.log (taken from client + server) to see where the desync started.

			[[Category:Engine Dev]]


	[[Category: ~~Development~~]]

2012-11-28T19:10:40Z

check for memory corruption with valgrind

← Older revision		Revision as of 20:10, 28 November 2012
Line 13:		Line 13:
	An first check should be, to run a desynced demo with valgrind with spring-headless:		An first check should be, to run a desynced demo with valgrind with spring-headless:
	<code><pre>		<code><pre>
	valgrind --log-file=valgrind.log spring-headless demofile.sdf		valgrind --trace-children=yes --log-file=valgrind.log spring-headless demofile.sdf
	</pre></code>		</pre></code>