You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The provided Go code leads to runtime errors, specifically a stack overflow, and in some cases, type conversion issues when certain lines are uncommented. This behavior is unexpected and may indicate underlying problems in the code.
There are multiple ways to play around this bug and potentially find new ones, basically try replacing some uncommented lines by commented ones.
From my current understanding, this code is actually bad, because it tries putting structs as DAO interface object instead of giving the pointer to the struct.
This mistake is sometimes completely ignored, and the code can run smoothly (bug1?).
In some other cases, there isn't a stack overflow but we can see conversion problem:
(bug2?) I believe the stack overflow occurs when we print the state of the variable using println(m.String()). It seems to be caused by a combination of a loop and the use of embedded structures.
To prevent loops when printing a recursive object, we can utilize a map to keep track of already printed pointers. However, it appears that the use of embedding may be causing this check to fail.
And finally (bug3?):
We should avoid stack overflow at all costs by making sure that we have all the runtime limit options and that the debugging features are always safe to run.
Update 1: I believe the stack overflow is due to a panic-recover-print loop, which is recursive.
The text was updated successfully, but these errors were encountered:
moul
changed the title
Stack overflow when printing machine state with type conversion, embedded structs and loops
panic: stack overflow when printing machine state with type conversion, embedded structs and loops
Oct 25, 2023
Addresses #1291. This is to fix the issue causing the entire interpreter
process to crash, not the underlying issue that is causing it to panic
in the first place.
---------
Co-authored-by: Morgan <morgan@morganbaz.com>
…1315)
Addresses gnolang#1291. This is to fix the issue causing the entire interpreter
process to crash, not the underlying issue that is causing it to panic
in the first place.
---------
Co-authored-by: Morgan <morgan@morganbaz.com>
The provided Go code leads to runtime errors, specifically a stack overflow, and in some cases, type conversion issues when certain lines are uncommented. This behavior is unexpected and may indicate underlying problems in the code.
Produces the following result:
There are multiple ways to play around this bug and potentially find new ones, basically try replacing some uncommented lines by commented ones.
From my current understanding, this code is actually bad, because it tries putting structs as DAO interface object instead of giving the pointer to the struct.
This mistake is sometimes completely ignored, and the code can run smoothly (bug1?).
In some other cases, there isn't a stack overflow but we can see conversion problem:
(bug2?) I believe the stack overflow occurs when we print the state of the variable using
println(m.String())
. It seems to be caused by a combination of a loop and the use of embedded structures.To prevent loops when printing a recursive object, we can utilize a map to keep track of already printed pointers. However, it appears that the use of embedding may be causing this check to fail.
And finally (bug3?):
We should avoid stack overflow at all costs by making sure that we have all the runtime limit options and that the debugging features are always safe to run.
Update 1: I believe the stack overflow is due to a panic-recover-print loop, which is recursive.
The text was updated successfully, but these errors were encountered: