Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More info about unreported fatal errors #15807

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

cameel
Copy link
Member

@cameel cameel commented Jan 31, 2025

Another iteration on #15185.

In #15185 I replaced rethrowing of unreported fatal errors with an assert. Back then it was pointed out that we're losing extra detail by doing that (#15185 (comment)). I thought it didn't matter because this kind of bug should be pretty uncommon and even then fixed quickly but some recent reports proved me wrong (#15600, #15601, #15722). This happens more often than I thought and apparently no one notices that this way of reporting a fatal error is a bug in itself so we're better off having that extra info there.

To be fair, I did add more info to the output back then - the message from the original exception - which should have been enough to avoid this. The problem is that ErrorReporter does not provide that message, probably assuming that the message in Error is what matters and the one from the exception will never be shown. The only thing we get is the exception type which often tells us nothing (it's just std::exception in all the linked cases).

I still don't think we should just rethrow an exception that someone might assume has to be handled. The PR fixes the issue by keeping the assert but also immediately reporting all the details about the FatalError at the point where it's caught. It also adds messages to all FatalErrors: both those thrown by ErrorReporter and a few cases where we throw them manually.

- It's not shown to the user but it's still useful because we can include it in the assert that gets triggered when a fatal error gets thrown but not reported.
@cameel cameel force-pushed the better-reporting-of-unreported-fatal-errors branch from 59e1a1c to c924df5 Compare January 31, 2025 19:55
@cameel
Copy link
Member Author

cameel commented Jan 31, 2025

Here's what the new reporting looks like (from #15601):

Unreported fatal error:
/solidity/liblangutil/ErrorReporter.cpp(143): Throw in function void solidity::langutil::ErrorReporter::fatalError(solidity::langutil::ErrorId, solidity::langutil::Error::Type, const solidity::langutil::SourceLocation&, const std::string&)
Dynamic exception type: boost::wrapexcept<solidity::langutil::FatalError>
std::exception::what: Arithmetic error when computing constant value.
[solidity::util::tag_comment*] = Arithmetic error when computing constant value.

Internal compiler error:
/solidity/libsolidity/interface/CompilerStack.cpp(516): Throw in function bool solidity::frontend::CompilerStack::analyze()
Dynamic exception type: boost::wrapexcept<solidity::langutil::InternalCompilerError>
std::exception::what: Unreported fatal error.
[solidity::util::tag_comment*] = Unreported fatal error.

Note that we unfortunately don't get the location of the code that should have reported the underlying error, but rather of the place in ErrorReported that throws the fatal error. At least the original message is there.

Still, not sure if the message in the assertion makes it clear that the fact that the error was not reported is a separate bug. Any ideas how to make it more obvious?

@matheusaaguiar
Copy link
Collaborator

matheusaaguiar commented Feb 4, 2025

Still, not sure if the message in the assertion makes it clear that the fact that the error was not reported is a separate bug. Any ideas how to make it more obvious?

I spent some time thinking about it and maybe best we can do here (without spending much more time on it) is to have it more explicit and obvious: Fatal error occurred but it was not reported by the compiler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants