- Fri Jun 09, 2017 3:41 pm
#66961
I think it worth mentioning some different perspective 'bug' observations in case it might help pinpoint the problem, because otherwise the bug could remain forever.
Stage 1.
The first sign of problems is when a script has grown sufficiently to cause a reboot when clicking SAVE.
This may not seem much of a problem at the time because the script says it has Saved ok in the browser status bar, and indeed may pop up the "Saved ok" confirmation window after the device has rebooted and reconnected, but it is just the beginning of an inevitable impossibly slippery slope.
Stage 2.
Eventually the rebooted interpreter fails to return a "Saved OK" confirmation, forcing a second SAVE.
Initially the rebooting only occurs with an interpreter which has done a previous SAVE, therefore a newly powered-up or re-booted interpreter will probably SAVE ok without a reboot, but subsequent SAVEs will likely cause a reboot, resulting in every alternate SAVE rebooting or succeeding.
This difference of behaviour suggests that additional (virgin or non-virgin) 'interpreter state' info is also being saved for subsequent interpreter use along with the actual script, else if it was just the script being SAVEd the results should be identical every time.
If the saved 'state' data is part of the problem it's possible (even likely) that all other symptoms such as quantum weirdess, script corruption and eventually interpreter corruption, are all just different extremes of the same root cause.
So if the interpreter is saving 'state' data as well as the script, it could suggest a problem with the writing of the 'state' data, ie: saving too big a block... causing it to outgrow its allocated area and bleed over things like the browser cache, and perhaps even the interpreter cache or program counter or REBOOT code (or whatever else might be able to actually trigger a reboot?).
It's quite possible that the interpreter may have been incorrectly saving it's 'state' data from day 1 without being noticed, until the saved state data grew sufficient to trespass out-of-bounds and bleed over the 'reboot' trigger and browser cache areas etc. Presumably the virgin state data is smaller, which would explain why a virgin SAVE doesn't trigger a reboot.
Stage 3.
Quantum weirdness starts when the browser fails to display some of the web components correctly, but with strange intermittent symptoms which may change each time the script is RUN. Simply doing a browser Back then re-RUN may cause previous problems to now display correctly but other web components to be wrong, often with different results for many re-RUNs, and perhaps eventually everything might display correctly.
This is not script corruption, else items that didn't display first time could never display correctly, so it would appear to be the browser cache that is being corrupted, and apparently different areas each time.
Stage 4.
Permanent script corruptions. Clicking EDIT would now load the corrupted script, but the corruption may not necessarilly be obvious or noticable. The unwary could chase many ghosts.
Stage 5.
Corruption of the Esp-Basic interpreter. Madness. Nothing can be trusted any more.
If a script is needed for demonstrating the quantum weirdness please ask, cos I have many such abandoned projects which have hit that brick wall.
If I had sufficient knowledge I would try to find out the resulting saved 'state data' memory differences between a virgin save and a non-virgin save, then perhaps try to populate the memory past their ends with tests data to see if it got overwritten when doing another SAVE, and by how much.
I can visualise the situation as putting one foot in front of the other, then laying a carton of eggs in front. I could raise and lower my front foot as much as I liked without problems... until I put on bigger boots - which would then stomp on anything in front.
My gut feeling is that all those problem stages mentioned above are just different numbers of broken eggs caused by the same growing footprint as it gets bigger.
I hope some of this might make some sense, and hopefully could help isolate the crippling bug once and for all.
Stage 1.
The first sign of problems is when a script has grown sufficiently to cause a reboot when clicking SAVE.
This may not seem much of a problem at the time because the script says it has Saved ok in the browser status bar, and indeed may pop up the "Saved ok" confirmation window after the device has rebooted and reconnected, but it is just the beginning of an inevitable impossibly slippery slope.
Stage 2.
Eventually the rebooted interpreter fails to return a "Saved OK" confirmation, forcing a second SAVE.
Initially the rebooting only occurs with an interpreter which has done a previous SAVE, therefore a newly powered-up or re-booted interpreter will probably SAVE ok without a reboot, but subsequent SAVEs will likely cause a reboot, resulting in every alternate SAVE rebooting or succeeding.
This difference of behaviour suggests that additional (virgin or non-virgin) 'interpreter state' info is also being saved for subsequent interpreter use along with the actual script, else if it was just the script being SAVEd the results should be identical every time.
If the saved 'state' data is part of the problem it's possible (even likely) that all other symptoms such as quantum weirdess, script corruption and eventually interpreter corruption, are all just different extremes of the same root cause.
So if the interpreter is saving 'state' data as well as the script, it could suggest a problem with the writing of the 'state' data, ie: saving too big a block... causing it to outgrow its allocated area and bleed over things like the browser cache, and perhaps even the interpreter cache or program counter or REBOOT code (or whatever else might be able to actually trigger a reboot?).
It's quite possible that the interpreter may have been incorrectly saving it's 'state' data from day 1 without being noticed, until the saved state data grew sufficient to trespass out-of-bounds and bleed over the 'reboot' trigger and browser cache areas etc. Presumably the virgin state data is smaller, which would explain why a virgin SAVE doesn't trigger a reboot.
Stage 3.
Quantum weirdness starts when the browser fails to display some of the web components correctly, but with strange intermittent symptoms which may change each time the script is RUN. Simply doing a browser Back then re-RUN may cause previous problems to now display correctly but other web components to be wrong, often with different results for many re-RUNs, and perhaps eventually everything might display correctly.
This is not script corruption, else items that didn't display first time could never display correctly, so it would appear to be the browser cache that is being corrupted, and apparently different areas each time.
Stage 4.
Permanent script corruptions. Clicking EDIT would now load the corrupted script, but the corruption may not necessarilly be obvious or noticable. The unwary could chase many ghosts.
Stage 5.
Corruption of the Esp-Basic interpreter. Madness. Nothing can be trusted any more.
If a script is needed for demonstrating the quantum weirdness please ask, cos I have many such abandoned projects which have hit that brick wall.
If I had sufficient knowledge I would try to find out the resulting saved 'state data' memory differences between a virgin save and a non-virgin save, then perhaps try to populate the memory past their ends with tests data to see if it got overwritten when doing another SAVE, and by how much.
I can visualise the situation as putting one foot in front of the other, then laying a carton of eggs in front. I could raise and lower my front foot as much as I liked without problems... until I put on bigger boots - which would then stomp on anything in front.
My gut feeling is that all those problem stages mentioned above are just different numbers of broken eggs caused by the same growing footprint as it gets bigger.
I hope some of this might make some sense, and hopefully could help isolate the crippling bug once and for all.
