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
This observation locates the reason, not the cause.
While attempting to resolve what was believed to be a garbage collection issue, as another user had posted an issue here around the same time as my discovery,
unrelated March 2 'Stack overflow when Garbage Collecting giant linked list #1765'
a trace() resulted in an endless loop. See thread:
And here we have an endless loop, should 'childRef' always be non zero. This does work, when the tree is in tact, but under a condition, still to be uncovered, as long as that argument is 'truthy' this
while can never exit. I always use an external software watchdog for while conditions, and try to avoid using while in the first place, as we humans can never predict all eventualities, and to be safe, use an additional counter to bail.
Through coercion, we know that an object is coerced to a string, then is coerced to a number, the conditional test is then evaluated on that number. Since the function jsvGetNextSibling is always pointing to it's array contents, it never returns null, undefined or NaN, and therefore isn't providing a zero value either.
Even more dangerous is a while constructed inside a recursive process.
Under 99.8% of cases this situation will never be encountered. For some reason, still unkown as of this date, memory becomes corrupt, providing an incorrect tree to the trace() function.
The text was updated successfully, but these errors were encountered:
Through coercion, we know that an object is coerced to a string, then is coerced to a number, the conditional test is then evaluated on that number
We are talking about C code here, so I'm not sure I understand what you mean. This obviously does work in the vast majority of cases because it's used all the time and this is the first time in 7 years anyone has reported an issue.
should 'childRef' always be non zero
But it won't be unless something has gone horribly wrong.
Wed 2020.04.29
This observation locates the reason, not the cause.
While attempting to resolve what was believed to be a garbage collection issue, as another user had posted an issue here around the same time as my discovery,
unrelated March 2 'Stack overflow when Garbage Collecting giant linked list #1765'
a trace() resulted in an endless loop. See thread:
Multiple occurances during a trace() output request along with suggested fix
I discovered the reason trace gets stuck in an endless loop.
Using link from Hardware Reference:
https://github.com/espruino/Espruino/blob/master/src/jswrap_interactive.c#L107
Clicking on the Right facing arrow takes me to the source:
Using VSCode
jsvar.c
L3544
int _jsvTraceGetLowestLevel(JsVar *var, JsVar *searchVar) {
L3561
while (childRef) {
L3565
childRef = jsvGetNextSibling(child);
ref: static ALWAYS_INLINE JsVarRef jsvGetNextSibling(const JsVar *v) { return v->varData.ref.nextSibling; }
At GitHub
https://github.com/espruino/Espruino/blob/master/src/jsvar.c#L3588
And here we have an endless loop, should 'childRef' always be non zero. This does work, when the tree is in tact, but under a condition, still to be uncovered, as long as that argument is 'truthy' this
while can never exit. I always use an external software watchdog for while conditions, and try to avoid using while in the first place, as we humans can never predict all eventualities, and to be safe, use an additional counter to bail.
Through coercion, we know that an object is coerced to a string, then is coerced to a number, the conditional test is then evaluated on that number. Since the function jsvGetNextSibling is always pointing to it's array contents, it never returns null, undefined or NaN, and therefore isn't providing a zero value either.
Even more dangerous is a while constructed inside a recursive process.
ref
https://javascript.info/ifelse
https://javascriptweblog.wordpress.com/2011/02/07/truth-equality-and-javascript/
Under 99.8% of cases this situation will never be encountered. For some reason, still unkown as of this date, memory becomes corrupt, providing an incorrect tree to the trace() function.
The text was updated successfully, but these errors were encountered: