Old "maintenance" builds used for BA autohosts
Moderator: Content Developer
Old "maintenance" builds used for BA autohosts
a lot of autohosts for BA still use old versions of spring from the maintenance branch. "104.0.1-151-g11de57d maintenance" is most common.
the most recent version is "104.0.1-303-g6a15411f7a maintenance"
is there a reason for using the old version?
it makes debugging / finding + fixing desync difficult.
the most recent version is "104.0.1-303-g6a15411f7a maintenance"
is there a reason for using the old version?
it makes debugging / finding + fixing desync difficult.
Re: Old "maintenance" builds used for BA autohosts
yeah cloaking behavior was removed from engine and dunno how to easily re-implement it.
I wrote a gadget that re-implements cloaking cost, but it doesn't decloak when enemy is in decloaking range or player has insufficient energy to cloak.
Then I gave up because there is no updated changelog for engine and you have to blindly encounter problems/changes as you test. I was told I should look at engine commits to know what changes.
I wrote a gadget that re-implements cloaking cost, but it doesn't decloak when enemy is in decloaking range or player has insufficient energy to cloak.
Then I gave up because there is no updated changelog for engine and you have to blindly encounter problems/changes as you test. I was told I should look at engine commits to know what changes.
Re: Old "maintenance" builds used for BA autohosts
desyncs are maybe due to gadget eating too much mem. (dunno which)
Is there a way to see how much mem a gadget uses?
(atm when you connect after a game has started and if you cant catch up withing time, you'll memory rise rapidly until the limit of 800MB is reached and lua gets disabled and sync errors occur)
Is there a way to see how much mem a gadget uses?
(atm when you connect after a game has started and if you cant catch up withing time, you'll memory rise rapidly until the limit of 800MB is reached and lua gets disabled and sync errors occur)
Re: Old "maintenance" builds used for BA autohosts
should be fixed by https://github.com/spring/spring/commit ... b8b642aa34 or https://github.com/spring/spring/commit ... e63dbb912e on the maintenance branch.Floris wrote:(atm when you connect after a game has started and if you cant catch up withing time, you'll memory rise rapidly until the limit of 800MB is reached and lua gets disabled and sync errors occur)
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Old "maintenance" builds used for BA autohosts
It's impossible to count, unfortunately. Within each lua state, there is no 'formal' division between what is a gadget/addon and what is other stuff, or which gadget/addon is which. There is nothing that tracks ownership/allocation of memory by particular source files, and it doesn't really make sense to try and do it because of libs, includes & massively frequent occurence of files calling each other functions, etc etc.Is there a way to see how much mem a gadget uses?
Re: Old "maintenance" builds used for BA autohosts
Actually, it is possible. Take a look at the widget profiler in chobby. It has a significant overhead so I'm not sure how accurate it is, but it measures mem consumption before and after every callin of every widget. In the end I think it used to dump the totals in the log.Silentwings wrote:It's impossible to count, unfortunately. Within each lua state, there is no 'formal' division between what is a gadget/addon and what is other stuff, or which gadget/addon is which. There is nothing that tracks ownership/allocation of memory by particular source files, and it doesn't really make sense to try and do it because of libs, includes & massively frequent occurence of files calling each other functions, etc etc.Is there a way to see how much mem a gadget uses?
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Old "maintenance" builds used for BA autohosts
That would be measuring something different to what I said - for example, it would not immediately be enough info to isolate a memory leak occuring within a library function called by one addon but defined within another. But, still useful in many cases, thanks for pointing it out!it measures mem consumption before and after every callin of every widget
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Old "maintenance" builds used for BA autohosts
So, after some clarification: It is possible to measure the total mem usage of lua states. It is not possible to sensibly define or measure "the amount of memory currently being used by widget/gadget X".
See https://github.com/Balanced-Annihilatio ... n/pull/104 for a version of the widget profiler (for the classic widget handler) that reports allocation rates per callin in Kbps.
See https://github.com/Balanced-Annihilatio ... n/pull/104 for a version of the widget profiler (for the classic widget handler) that reports allocation rates per callin in Kbps.
Re: Old "maintenance" builds used for BA autohosts
atm some hosts use spring 104.0.1-138-gf1944b maintenance which isn't available for download any more. the same for spring 104.0.1-151... maintenance
see https://springrts.com/dl/buildbot/default/maintenance/
(maintenance + develop branch builds are automatically deleted after ~120 days: https://github.com/spring/spring/blob/d ... cleanup.sh )
see https://springrts.com/dl/buildbot/default/maintenance/
(maintenance + develop branch builds are automatically deleted after ~120 days: https://github.com/spring/spring/blob/d ... cleanup.sh )
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Old "maintenance" builds used for BA autohosts
I think 120 days is not ideal e.g. if only a little more time had passed between some commit and https://springrts.com/mantis/view.php?id=5992, bisection may well have been impossible without forced re-builds.
Re: Old "maintenance" builds used for BA autohosts
120 days is because of the limited disk space.