newRPL - build 1255 released! [updated to 1299]

[Claudio L.]

(06-24-2019 10:51 PM)JoJo1973 Wrote:  

(06-24-2019 01:34 PM)Claudio L. Wrote:  Great to hear! Some memory corruption must've happened while you were bug-hunting and crashing the calc on purpose to reproduce them. However, your service is crucial to the project so please don't stop doing it :-), just backup often to different files to make sure you don't lose anything.

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.