fix: catch the out of gas exception in preprocess

[piux2]

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[codecov]

Codecov Report

Attention: Patch coverage is 25.00000% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
gnovm/pkg/gnolang/preprocess.go	25.00%	2 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[thehowl]

Conceptually the same as this PR

Do you think it could make sense to swap with using errors.As, as I suggested here?

Also, do you have a testcase that can show what happens when there's an out-of-gas in preprocess/predefine? (that's what we were missing on the other PR)

[piux2]

Conceptually the same as this PR

Yes, Same. This PR catch all places that could throw Out Of Gas Exception in preprocess.

Do you think it could make sense to swap with using errors.As, as I suggested here?

Using return errors in preprocess will change many signatures and also involves catching errors in recursive calls during transcribe. It will be easier to make mistakes in future changes not handling errors or shadowing error in closures and switch case block. Recover and throwing panic(r) is a clearer and simpler approach.

I would prefer panic everywhere with exceptions in the VM itself and catch the panics outside of VM and process them as errors in Keeper.

In addition, to handle it properly, an OutOfGas exception should be thrown all the way to the ante handler and base app where the gas meter was originally set.

Also, do you have a testcase that can show what happens when there's an out-of-gas in preprocess/predefine? (that's what we were missing on the other PR)

I will add testing cases.

[thehowl]

Using return errors in preprocess will change many signatures and also involves catching errors in recursive calls during transcribe. It will be easier to make mistakes in future changes not handling errors or shadowing error in closures and switch case block. Recover and throwing panic(r) is a clearer and simpler approach.

I'm not suggesting we returns error. Simply, that we are panic'ing with an error type; the value returned by recover() in the keeper will be of the same type too. So we can use errors.As instead -- thus we can special-case how we handle OutOfGasException in the keeper rather than in the VM.

The advantage I see out of this is that we don't have to think to add a condition to not wrap the error any other time we add a recover in vm. (They should happen seldom; but anyway I think the responsibility to do this kind of handling relies in the keeper).

[piux2]

I found right gas amount to replicate the errors that PR2368 could not reproduce and added proper integration test for that. Both store.GetPackage and store.GetTypeSafe could cause out-of-gas exceptions during preprocess.

I'm not suggesting we returns error. Simply, that we are panic'ing with an error type; the value returned by recover() in the keeper will be of the same type too. So we can use errors.As instead

using error.As() adds additional unnecessary abstraction.

We do use different exception types for VM panics. OutOfGasException and PreprocessError are the examples. To use errors.As(), we not only have to wrap exceptions with errors in VM, but also when we recover from a panic in Keeper, instead of type switching on r.(type), directly, we need to use r.(type) checking for error first and if else errors.As(r, &Exception) for the r=recover(). On the other hand, type switching exception types on recover is cleaner and faster than type checking error with if-else blocks.

we can special-case how we handle OutOfGasException in the keeper rather than in the VM.
I'm not suggesting we returns error. Simply, that we are panic'ing with an error type; the value returned by recover() in the keeper will be of the same type too. So we can use errors.As instead -- thus we can special-case how we handle OutOfGasException in the keeper rather than in the VM.

It only works if we do not recover any panic and wrap additional information on the call path to the Keeper. However, this is not the case. Currently, we recover from panic, wrap the stack trace, and preprocess trace in PreprocessError. Therefore, we need to differentiate the OutOfGas execution in the VM. This is actually the root cause of the issue we are fixing.

[MikaelVallenet]

Hello, I wanted to report the issue, then I saw that the problem was already being fixed, to check, I cloned the fix branch, install gno from this branch and I have the impression of still having the problem, or is it something else? @piux2

https://www.loom.com/share/4c507cb56f0e45b6bec819fdd85c6152?sid=558ebe55-0cb8-4758-ac76-1fe87584d69b

[piux2]

Hello, I wanted to report the issue, then I saw that the problem was already being fixed, to check, I cloned the fix branch, install gno from this branch and I have the impression of still having the problem, or is it something else? @piux2

https://www.loom.com/share/4c507cb56f0e45b6bec819fdd85c6152?sid=558ebe55-0cb8-4758-ac76-1fe87584d69b

@MikaelVallenet thank you for the feedback.

This is a normal case and not an issue. The chain checks the size of the transaction and consumes gas based on that size. The transaction runs out of gas before it reaches the VM.

gno/tm2/pkg/sdk/auth/ante.go

Line 108 in 763bdd1

newCtx.GasMeter().ConsumeGas(params.TxSizeCostPerByte*store.Gas(len(newCtx.TxBytes())), "txSize")

For the issue we are trying to solve in this PR, the out-of-gas event happens during preprocessing. Before the fix, it returned the stack trace and preprocess stack. After the fix, it returns a normal out-of-gas message and stack trace, as seen in your video clip.

The issue is tricky to reproduce. Only a specific gas amount will be able to trigger it. You can try it out in the newly added txtar file and compare the results before and after the fix.

[MikaelVallenet]

Hello, I wanted to report the issue, then I saw that the problem was already being fixed, to check, I cloned the fix branch, install gno from this branch and I have the impression of still having the problem, or is it something else? @piux2
https://www.loom.com/share/4c507cb56f0e45b6bec819fdd85c6152?sid=558ebe55-0cb8-4758-ac76-1fe87584d69b

@MikaelVallenet thank you for the feedback.

This is a normal case and not an issue. The chain checks the size of the transaction and consumes gas based on that size. The transaction runs out of gas before it reaches the VM.

gno/tm2/pkg/sdk/auth/ante.go

Line 108 in 763bdd1

newCtx.GasMeter().ConsumeGas(params.TxSizeCostPerByte*store.Gas(len(newCtx.TxBytes())), "txSize")

For the issue we are trying to solve in this PR, the out-of-gas event happens during preprocessing. Before the fix, it returned the stack trace and preprocess stack. After the fix, it returns a normal out-of-gas message and stack trace, as seen in your video clip.

The issue is tricky to reproduce. Only a specific gas amount will be able to trigger it. You can try it out in the newly added txtar file and compare the results before and after the fix.

Hello, thanks for information but i mean not the first error but the second one around 0:55 of my video (cf. screenshot below)

I think it should print the out of gas exception, isn't ?

[piux2]

@MikaelVallenet

I think it should print the out of gas exception, isn't ?

Have you checked if you ran the test against the correct version of the chain?

I noticed you only ran make install. Did you start the chain with the patch?

Also, here is the stack trace from the video at 1:04.

At line numbers preprocess.go:137 and preprocess.go:173, they do not match the code that follows the trace in this fixed patch.

[MikaelVallenet]

@MikaelVallenet

I think it should print the out of gas exception, isn't ?

Have you checked if you ran the test against the correct version of the chain?

I noticed you only ran make install. Did you start the chain with the patch?

Also, here is the stack trace from the video at 1:04.

At line numbers preprocess.go:137 and preprocess.go:173, they do not match the code that follows the trace in this fixed patch.

I see, indeed i did not start chain w/ patch thanks for clarification 🙏

[thehowl]

Let's change the test and merge this; I'd rather we did it slightly differently but I'm happy to do a follow-up PR myself.

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• SKIP: Do not block the CI for this PR

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 The pull request head branch must be up-to-date with its base (more info)

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

The pull request head branch must be up-to-date with its base (more info)

If

🟢 Condition met
└── 🟢 On every pull request

Then

🟢 Requirement satisfied
└── 🟢 Head branch (piux2-patch-1) is up to date with base (master): behind by 0 / ahead by 9

Manual Checks

**SKIP**: Do not block the CI for this PR

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission