I was learning B/S debugger basics today and have to say find it jaw-dropping how easy it is to crash Roku with only a few keystrokes (5, if i count them: “a\nda\n”). Here is how it looks:
BrightScript Debugger> a
Syntax Error. (compile error &h02) in $LIVECOMPILE(229)
BrightScript Debugger> da
070: Sub WaitMessage(port) As Object
071: while true
J000 81 pushbool true
90 01 iffalse J001 'addr=25
...
229: a
Connection to host lost.
Whoops, what happened? Not only did i get kicked out of the console but in a few seconds the whole box reboots. What a mess!
It was not my intent to crash it. At first thought it randomly reboots when in console, took me a while to pinpoint a sequence. Seems that any syntax error followed at any time later by ‘da’ causes it. i am guessing because there is invalid opcode, disassembler does not know how to handle (or 0 length or some such).
But it is creepy, it means i’d have to be vewy, vewy careful what i type in the console or sudden death is imminent. How do i even clear such condition without reboot?
“RokuJoel” wrote:
You just found a bug. It really isn’t that common to crash the debugger like that. Looks like that issue exists on 4.2 and not on 3.1
Yes, i know it is a bug. I get it only in rOS4 too, which is mildly disturbing (why is there a schism in non-architecture dependent code base?). I would expect bugs in the console, yes - it’s not a place QAs would be sent to test but reboot, really - can’t exit with more grace to home screen?
RokuCo,
would you please consider fixing this, so that player does not crash? Was bug ever entered on this?
This crash happens very reliably (on 3xxx series) - it is more reliable than ctrl-C entering debugger mode (since often ctrl-C exits dev channel for no raisin). All that is needed is issuing “da” (to see the bytecode) after there has been “Syntax Error” on previous command - reboot happens when listing reaches the position where syntax error was. My semi-wild-ass guess is part of a structure remains uninitialized / with random stack data. Glance at the 3rd number of the “ld”, normally it is the offset of line’s last bytecode - not so for lines 99-102:
I must be one of only a few around looking at bytecode, since i don’t see others complained in two years. Occasionally I find it educational/enlightening though - for example let me understand why/how “eval()” is leaking.
I don’t think many developers type random nonsensical commands into the debugger console…Still would be neat to have the sandbox actually behave like a sandbox rather than a current application running in an application debugger session within a second sandbox.
Yes, I filed a bug on this exact issue on 12/31/2011 against firmware 4.x
I’m pretty sure you don’t even need a syntax error to reproduce, copy paste from the bug report:
side load a BrightScript channel. Telnet to the device on port 8085. Press ctrl-c to interrupt the program and exit to the debugger.
At the BrightScript prompt type:
BrightScript Debugger> a
press enter
then type:
BrightScript Debugger> da
press enter.
...this appears to cause the device to reboot.
“RokuJoel” wrote:
Yes, I filed a bug on this exact issue on 12/31/2011 against firmware 4.x
I’m pretty sure you don’t even need a syntax error to reproduce, copy paste from the bug report:
Thanks, good to know at least it was reported.
FWIW, that example relied on syntax error happening (as seen in the first topic of thread). Today’s development is that crash may occur without an error/typo - and both fw3 and fw5 (before it was only the new fw). It might be a different bug even.
I understand this may never be fixed as matter of priorities; albeit bothered it’s likely something trivial like missed else or default case.
“EnTerr” wrote: Nobody is typing “random nonsensical commands into the debugger console”
More likely that nobody is typing “da” into the debugger console. I type random nonsensical commands all the time. I just don’t ever try to view the bytecode.
FWIW, I usually hit ctrc-c once the channel starts loading to verify it won’t crash while I want to debug something, or if I have an implicit stop in the code. I’m guessing most have seen the pattern, but it will crash the debugger every other time.
“ljunkie” wrote:
FWIW, I usually hit ctrc-c once the channel starts loading to verify it won’t crash while I want to debug something, or if I have an implicit stop in the code. I’m guessing most have seen the pattern, but it will crash the debugger every other time.
This has been an issue since the release of the Roku2 XS, and it made its way backwards to the 3.1 firmware platform as well. A bug has been filed. Note that this is a different issue - the issue that was being discussed in this thread, if I’m not mistaken, is an actual crash of the Brightscript environment itself and the resulting reboot of the device.
Yep, didn’t mean to hijack as it’s not the exact same issue, but I figured I’d put in my two cents in case anyone came to this thread. Thanks for letting us know there is a bug report, it’s second nature now so I’ll probably keep doing it even if fixed
“RokuJoel” wrote:
“ljunkie” wrote:
FWIW, I usually hit ctrc-c once the channel starts loading to verify it won’t crash while I want to debug something, or if I have an implicit stop in the code. I’m guessing most have seen the pattern, but it will crash the debugger every other time.
This has been an issue since the release of the Roku2 XS, and it made its way backwards to the 3.1 firmware platform as well. A bug has been filed. Note that this is a different issue - the issue that was being discussed in this thread, if I’m not mistaken, is an actual crash of the Brightscript environment itself and the resulting reboot of the device.
Nobody is typing “random nonsensical commands into the debugger console”
