newRPL - build 1255 released! [updated to 1299]

[JoJo1973]

(06-25-2019 03:06 AM)Claudio L. Wrote:  

(06-24-2019 10:51 PM)JoJo1973 Wrote:  Oh, I've found some interesting ways to crash the calc )) , in fact there's one I want to verify with the new build... I'll keep you informed!

BTW I probably found the culprit of the memory corruption: a formerly good dirobject that now hangs the calc when I enter it; curiously I can retrieve its contents if I use a program to enter it and RCL a variable in it.

I tried to PGDIR it, but the calc errors with an Out of Memory error. It's not a problem since I can wipe out the memory and have plenty of backups: one of them will be surely ok.

My question is if is it possible in the future to add a command like UserRPL PINIT that returns the memory to a sane state so that a corrupted object can be safely purged (recovery of the corrupted object wouldn't be important)?

There's no need for a specific command. Every time you turn the calculator on, or restore a backup, the entire memory is scanned and every single object is checked for validity. Of course, validity depends on the object type: a real number for example, as long as it has consistent headers is deemed valid, if some digits got corrupted it can't be detected (I'd have to waste a lot of memory in storing a CRC for every object). Any invalid object is purged (but this is extremely rare, hardly ever happened). Directory entries are scanned and checked for validity names as well. Invalid names with valid objects are given an 8-letter name.
As I find more creative ways to corruption memory, I also find ways to improve the sanity checks.
Now I don't want this to sound like newRPL is unstable, memory corruption is extremely rare, and mostly due to testing unfinished, buggy code that 90% of the time never gets to the final user. In your case, you are trying to crash it on purpose to help the project, and your success means you might corrupt your memory every now and then.
Because backups do sanity checks, most of the time recovering from backup fixes any issues, even if the backup was done after the corruption happened.

I'll see if I can harden detection of malformed directory structures during the sanity checks, can you describe in more detail which things crash your bad directory and which ones work OK? This way I can at least try to guess what could be wrong and add a sanity check for it.
For example, you mentioned entering the directory crashes. I need to know exactly what happens in all of the following cases:
Entering from the menu?
Typing the name then doing EVAL?
Executing the unquoted name within a program?
Going into the bad directory then doing UPDIR?
In the parent directory, type the name quoted, then do RCL, do we get a DirObject? If so, go to HOME, type another name and do STO. This does a deep copy of the entire subtree, does it crash? If not, is the copy having the same issues as the original?
Going into the directory then doing PATH, does it crash?

To avoid annoying our readers, perhaps you should create the issue in the bug tracker and add all this info.

Ok, I'm preparing a bug report answering all the question provided. I can confirm that newRPL is pretty robust: it's likely that the object stayed corrupted for a while, and overall the system was unaffected and worked very reliably.

Moreover, as you remember I failed to flash build 1261 but succeeded to reflash build 1255 after each failed attempt: every time I recovered programs and settings without any loss (I can safely assume that it was the pre-existence of the corrupted dir the cause of the failures) - quite an accomplishment!