[bug/portal_loop] runtime error: index out of range [2] with length 0 while deploying certain realm on poral-loop
#2283
Comments
r3v4s
added
help wanted
🐞 bug
|
Okay, leaving an update on my current investigation. Replication set-upI'm running a gno.land node with this genesis.json. This is a trimmed-down version of the portal loop genesis.json. With this genesis.json, publishing succeeds. To run using this genesis file, you'll need to change the validators key so that your local instance is a validator. You can get the fields you need from Then, I'm running the node with this command: This allows me to reset the node and start from this genesis. I get the logs redirected to FindingsRunning the replication step pointed above by @r3v4s: As I said in the previous section, publishing succeeds with the provided genesis.json. However, it won't if you first broadcast this transaction: feeds-add.json. (This should work by simply doing After that, you get the panic pointed above. (This error happens also if the transaction is in the genesis). The surprising, and most revealing, fact about this is that if you re-start the node (without clearing the database/state); then publishing works as normal. SuspicionsLooking through some logs, my suspicions are:
That's it for this week, I may continue this another time. |
|
Note: I'm trying to get a txtar working before doing an actual fix. If my suspicion is correct, then we'll probably need to discuss either a) removing the caches from the Store (and just using the tm2 store cache), which does support transaction rollback properly, or b) creating a cache system in the Store that can properly handle rollbacks/commits. |
|
#2319 I found a way to replicate the issue; don't know if I'll have time to fix it though I'm thinking that attempting to fix it would mean trying to make |
|
I'm prioritizing a fix for this one in the next week, to be ready by Gophercon |
github-project-automation
bot
moved this from In Progress
to Done
in 🧙♂️gno.land core team
…ang#2504) Fixes gnolang#2283 (with a different approach from gnolang#2319) This PR loads all the standard libraries into the database when vm.Initialize is called. It doesn't fully fix the problems that gnolang#2319 is trying to address, but it does fix the most immediate bug of not being able to publish certain packages on portal loop. With these changes, we don't need a PackageGetter on-chain anymore. All packages are already loaded into the store, thus solving the problem @jaekwon was talking about [here](gnolang#2319 (comment)) at its root. This PR has a problem, which is that adding loading the entire stdlibs in the VM initialization step brings a huge overhead computationally; this is not a problem on the node, but it is when testing as it needs to happen very often. This translates to 2x slower txtar tests, compared to master. On my PC, it adds a 2-3 second overhead whenever running Initialize. I tried working out on a system which could save the data to quickly recover it, at least for some cases where we need to Initialize often; [see this diff](https://gist.github.com/thehowl/cb1ee79e63cf77d3f323730580eb2d18). But I didn't get it to work so far; after copying the DB, attempting initialization crashes because [ParseMemPackage is being handed a nil package, for some reason](https://gist.github.com/thehowl/d1efa51858d865fb5beb9c3a9cb0eeef). @gfanton, any tips?? :)) I'd want to avoid lazy loading in the node, as that's what got us here in the first place. <details><summary>Contributors' checklist...</summary> - [ ] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [x] Provided any useful hints for running manual tests - [x] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details> --------- Co-authored-by: Manfred Touron <[email protected]>
Description
We're trying to deploy our realms against portal-loop, but pool realm is failing while
gnokey maketx addpkgwith below error.Steps to reproduce on LOCAL [couldn't really reproduce on local. it doesn't panic, but succeeds]
unable to reproduce this issue on local chain, seems to be happening only in portal-loop.
Tried below ways on portal-loop, but none of them succeeded
gas-wantedto maxExpected behaviour
pool should be deployed
Actual behaviour
panic
FYI
There is realm that imports pool realm, such as position
Since deploying pool has been failed on portal-loop, deploying position needs to be fail with message like
unknown import found gno.land/r/demo/pool. However deploying position also panic with same error(index ouf of range)The text was updated successfully, but these errors were encountered: