-
-
Notifications
You must be signed in to change notification settings - Fork 21.5k
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
On bad array access error, bubble up the error #99914
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi there! Thanks for your PR.
Unfortunately, for the reasons I stated, you will need to change your code to handle errors in a Godot-way that is not relying on a try/catch.
(You can search the codebase, there is a lot of error handling by passing Error *r_error
as a parameter if the function called returns something already)
98f4d2a
to
3be6015
Compare
3be6015
to
e5030f3
Compare
Sorry for requesting review again before passing tests. I thought I had to request review in order to see test results. |
Addresses issue #98519 "Importing a large 400mb gltf/glb file crashes at 99%"
I would like to correct something incorrect that I said in a previous comment. I erroneously said before that upon importing the corrupt glb file to a new Godot project for the first time, it would remain unresponsive indefinitely. This was not actually the case. In truth, Godot only remains responsive for a very long time (about 10 minutes on my machine) but it will eventually arrive at the bad unsigned integer square brackets operation that I described, whether on the first try or any succeeding tries.
My fix does resolve the crashing for this case. It eventually returns Godot to a responsive state (as opposed to being unresponsive indefinitely), and communicates the error via notifications and on the console. It notably does NOT revert the state of the project to prior to the corrupt import.
After the exception is caught:
I believe the red X icon in the FileSystem correctly indicates that the file is corrupt, which is nice.
Additionally, I am under the impression that throwing an exception from the STD library is unconventional in the codebase but I am not familiar with the desirable standard.
I would be very pleased to make whatever modifications are seen fit.