Operating system or device - Godot version:
Linux. Godot 2.1.4 at commit 171d8a5.
Issue description:
Godot crashes when trying to run sqrt(-1) or log(-1).
Steps to reproduce:
print(sqrt(-1)) or print(log(-1)) under _ready().Additional info:
Terminal output when trying to run the scene:
ERROR: operator[]: SEVERE: Index p_index out of size (size()).
At: core/vector.h:136.
When I open godot, select the project and click the edit button, the same error appears and the program freezes.
This bug is not on 2.1.3.
I'll check this.
El 9 jul. 2017 8:54 p. m., "anakimluke" notifications@github.com escribió:
Operating system or device - Godot version:
Linux. Godot 2.1.4 at commit 171d8a5
https://github.com/godotengine/godot/commit/171d8a501ff97d4655ba4a7317822d41474eb4bc
.Issue description:
Godot crashes when trying to run sqrt(-1) or log(-1).Steps to reproduce:
- Create a new project, add a node and a script.
- Put print(sqrt(-1)) or print(log(-1)) under _ready().
- Run the scene.
- The editor will crash.
Additional info:
Terminal output when trying to run the scene:ERROR: operator[]: SEVERE: Index p_index out of size (size()).
At: core/vector.h:136.When I open godot, select the project and click the edit button, the same
error appears and the program freezes.This bug is not on 2.1.3.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/9580, or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQCtrZMsCLs1mVr7fx3h4lkwEeqzHm8ks5sMSH-gaJpZM4OSJl-
.
The problem is at the GDCompiler.
Since (NaN == NaN) == false, the HashMap is re-inserting the assumed-existent key.
For me different things happen because of this: either the reported behavior or just a warning print with no crash.
I'm not sure how to handle this. Options:
HashMap, but that may damage performance everywhere;__UPDATE:__ Whatever the fix, this seems to affect both 2.1 and 3.0, so it will need to be (back)ported.
alternatively sqrt and log can return a complex number variant :D (just kidding)
@reduz, what do you think?
I probably can fix it according to your directions (with no naughty merging XD).
Are you sure this is still a problem in 3.0? I'm pretty sure this behavior is fixed in 3.0 since #7815 and I can't reproduce it on master. In my tests it just prints '-nan' as expected.
I can backport it to 2.1 if people think it's worth doing.
Anything that prevents crashes worth doing :D
@akien-mga do you want this in 2.1?
I can confirm this doesn't happen in 2.1.3 either, so I guess this is a different regression. Either something from 3.0 got backported without the nan for-non-math operations fix, or something was 'just' broken.
Backporting the feature from 3.0 doesn't make much sense in the latter case.
If someone is up for a git bisect, that would be cool :)
I bisected the issue to 14e30c3faadd8d53f0b8005d5100b33fcae489c5 I haven't yet looked at the commit to see what the problem may be. Testing a build with just this commit reverted to ensure this really is the problem.
Update: Just reverting that commit fixes the issue. I'll try to find out why.
The specific part of the diff that causes this issue is this:
- zeromem(ringptr, sizeof(RingPtr) + ringptr->size);
+ memset(ringptr, 0xEA, sizeof(RingPtr) + ringptr->size);
I suspect that the hashmap expects that all members are zero but with this commit they are now 0xEA. Exactly why this only fails in this case isn't entirely clear to me.
This is actually not the whole story, while this does 'fix' the crash doing
print(sqrt(-1))
print(sqrt(-1))
only prints -nan once, not twice. On 2.1.3 and 3.0 it does print twice. I think that this commit 'causing' the crash is a red herring.
I'll do another set of bisections to figure out what commit caused it to only print once, or crash, I think that's probably the real culprit here.
I have the same problem (-nan only printed once) when building 8df5b7151f9682e851b6c1c9ff1e13a32190b532 I'm building a release_debug build now to see if the problem remains or not.
ok, yeah so... at 2.1.3:
$ ~/src/godot/bin/godot.x11.opt.tools.64
-nan
-nan
$ ~/src/godot/bin/godot.x11.tools.64
ERROR: next: Condition ' !e ' is true. returned: __null
At: core/hash_map.h:507.
-nan
I'll try to do a build from the tip of the 2.1 branch in release_debug too see what we get then.
Given that this does happen in 2.1.3 I'm going to have to assume that @RandomShaper was correct. In that case backporting #7815 will probably fix this problem.
Fixed by #10490.
Most helpful comment
alternatively sqrt and log can return a complex number variant :D (just kidding)