Present: <abma>, <hoijui>, <jk>, <kloot>, <tobi>, <zerver>
<tobi> FYI buildbot interface is now at http://buildbot.springrts.com (old address is 301 redirect to that)
<tobi> though you probably noticed already
<hoijui> nice, thanks
<abma> nice! no, didn't see that yet
<hoijui> dont have to move around link between machines anymore
<tobi> :7778 wasn't that hard to remember right? :)
<hoijui> before, with the port, i could not keep it in head
<hoijui> it was
<abma> aaah, ok :D
<hoijui> its not like i need it every day
<hoijui> just when using an other pc
<hoijui> else i have it in browser session, one tab
<tobi> abma: also, on zydox box there's now an nginx that hosts the docs, his web box proxies to this
<tobi> just FYI
In short: a simpler web address for buildbot
<abma> what's missing?
<abma> major bugs known?
<abma> testing needed?
<jk> crash bug seems fixed
<jk> a desync is left
<jk> possibly caused in air code
<abma> is there a bug-report / howto reproduce?
<hoijui> well. jk knows about it.. possibly not needed
<jk> non yet
<jk> desyncs aren't that easy to reproduce
<abma> replays available?
<jk> demos don't seem to desync here
<abma> maybe demotool can help, if there are few commands in the last frames before the desync
<abma> or valgrind maybe
<abma> do you have more infos?
<abma> i don't want to start at zero :)
<abma> or do you want to fix it alone?
<jk> duno how to reproduce desyncs
<jk> only could reproduce crashes
<jk> so I don't have more infos
<abma> ok, will try...
<jk> also detected them just 1h ago
<abma> infolog.txt maybe?
<jk> after I hoped I fixed everything :<
<abma> hm :-/
<zerver> imo we are not delaying the 84 release because of some hard to reproduce desync
<jk> they happened in 2 of 2 matches
<zerver> there is one mantis report about an MT desync also, but that may be coincidence
<abma> then easy to reproduce, it takes just to long to get a desync
<hoijui> you said you believe it is in air code..
<hoijui> should we play some games without air, and some wiht lots of air?
<zerver> lets go :)
<jk> already told the guy I am testing with to build air
<hoijui> i cant play on this machine
<jk> match is running atm
<jk> hmm could be planes or gunships
<jk> didn't really tested planes yet
<jk> hmmm no desync in a 24mins match with a lot of air (gunship & planes)
<jk> with him playing vs. cai and me speccing
<hoijui> so maybe uhm again?
<hoijui> or were you also speccing in the desyncing games?
<jk> nah before I played
<jk> and build shields
<jk> possibly it's another shield bug
<hoijui> mm ok
<jk> desync \o/
<zerver> I just ran it thru MSVC debugger, heap corruption detected in ~CUnitScript
<jk> very very likelly caused by shields
<jk> and possibly when they die
<abma> zerver: no specific code-line?
<zerver> i have the full trace, but the actual corruption may be done elsewhere
<abma> ah, ok
<zerver> will do some testin
<abma> i still get theses stacktraces when watching the testgame: http://springrts.com/mantis/view.php?id=2703
<abma> "AddDeathDependence: Duplicated listener object for dependence type 10 "
<abma> game is still running, more infos will follow :)
<jk> even with release-branch-136?
<abma> one example: http://pastebin.com/DDpuimqj
<abma> uh, sorry seems to be incomplete
<zerver> i got it now with page heap. yep, plasmarepulser
<zerver> incomingProjectiles contains deleted items...
<jk> are you sure you are using latest release branch?
<zerver> no, develop
<abma> damn :-/
<abma> but this bug could be in release, too!?
<jk> they are fixed in release branch
<jk> (not abma's)
<abma> yep, i tested release branch...
<zerver> we may not be talking about the same bug
<abma> in general the desync bug
<zerver> the shield bug
<jk> I would say we need a syncdebug match tomorrow or just further code inspection
<jk> and yeah, it's near proven to be shields related
<jk> 2 matches I build shield & sometimes when they got killed we desynced
<jk> 1 match with 90% of time no desync, then started shields and massively attacked them with air, kbot, tanks -> desync
<jk> and 1 match w/o shields at all (>30mins) no desync
<zerver> which commit in release branch supposedly fixed shields?
<jk> you should just switch to release branch
<jk> and compile it instead of develop
<jk> but this is the commit https://github.com/spring/spring/commit ... 95438a0fe5
<jk> (the other ones add additional assert's to get non-corrupted stacktraces)
In short: a crash/desync bug currently blocks the release
Dev meeting minutes 2011-11-14
Minutes of the meetings between Spring developers are archived here.
2 posts • Page 1 of 1