The bug is applying all messages from given From address are priors
before appling the message that we are estimating.
If user tries replacing message in the middle with gas limit estimation
then message sequence is off and user will either get an execution error
or gas mis-esimation.
Resolves#5402
Signed-off-by: Jakub Sztandera <kubuxu@protocol.ai>
This pulls in the improvements introduced in:
- https://github.com/raulk/go-watchdog/releases/tag/v1.0.0
- https://github.com/raulk/go-watchdog/releases/tag/v1.0.1
Lotus tries to initialize the watchdog in the following order of precedence:
1. If a max heap limit has been provided, initialize a heap-driven watchdog.
2. Else, try to initialize a cgroup-driven watchdog.
3. Else, try to initialize a system-driven watchdog.
4. Else, log a warning that the system is flying solo, and return.
This PR also enabled automatic heap profile capture when memory usage
surpasses 90% of the limit. Profiles are written to <LOTUS_HOME>/heapprof.
A single heap profile is captured per episode, with a max of 10 episodes
captured during the lifetime of the process. Episode = instance of usage
climbing above the 90% threshold.
The aim is to put some negative pressure on gas-premium instead of
maintining status quo.
55th percentile instead of median should not make much difference for
block inclusion timing.
Signed-off-by: Jakub Sztandera <kubuxu@protocol.ai>
_Always_ (almost) use the tipset's parent state, instead of computing.
Exceptions:
* MinerGetBaseInfo. Fixing this would break things so we need to be
careful (although we could bump the API version, fix it, then fix the call
sites).
* StateReplay. This is replaying a message on top of the given tipset.
* GasEstimateGasLimit. This executes the message on-top-of the tipset's
computed state (unlike call which executes it on the tipset's parent state).
* Having this method and Call apply the message at different heights is really
weird.