DPS8M segfaults if 'dps8m.state' file exists and has wrong permissions

[Alchemist2]

Checked with: Raspberry3B, Raspbian Buster. 'dps8m.state' is a good idea, because it allows freezes/restart without having to reboot each time. However:

• It's usage should be optional.
• If the file exists and is not readable, the program should either exit gracefully, or ignore it. A command line option would be great.

[charlesUnixPro]

I am disinclined to make its usage optional.

I terms of simulator fidelity, the core memory of the original hardware was non-volatile, and should be preserved across simulator runs.

By placing the memory in a named shared memory segment, the simulator does not have to attempt to save memory after an emulator crash; the state file is always up to date.

In addition, the state file enables real-time analysis, as used by XRAY and the blinking-lights display, and the Multics debug tools that I have been developing to understand the bad config deck bug.

I don't have a problem with improving the management of the name space, especially the (un-reported) issue of the state-file being opened by a second emulator process and crashing things badly.) However, I am a bit uncertain as to the use-case here... Why would the permissions be wrong? There are many things in the environment that can be changed to the detriment of the emulator; to some extent the developers needs to draw lines in the sand and say "Don't do that."