On Mon, Aug 17, 2020 at 10:23:10PM +0100, Aaron Sloman wrote:
> I recently acquired a new PC from chillblast to replace my ancient desktop
> machine (Viglen) at home. I had a lot of problems setting it up (e.g.
> handling screen resolution), that I still don't understand, but it is now
> working very well running Fedora 32 (I had some problem I could not fix on
> F31, but that may well have simply been my linux incompetence.)
>
> I got poplog running fairly soon (using getpoplog.sh) and it works fine
> with and without motif, so that I was very soon able to give up using nano
> to set up linux files and use ved instead. (I've never used 'vi'.)
>
> But there was an obscure problem that I've fixed, but don't understand!
>
> I kept finding that if I edited a file for a long time (e.g. using ved to
> create a large html file) ved would sometimes crash with this message,
> leaving me with a pop11 prompt:
>
> <<<<<<< Access Violation: PC = 00007FFFF7B12890, Addr = 00000007FF6200F0,
> Code = 1 >>>>>>>
>
> ;;; MISHAP - serr: MEMORY ACCESS VIOLATION (see above)
> ;;; PRINT DOING
> ;;; DOING : do_autosave_backup check_and_save_file check_autosave
> rawcharin runproc
> ;;; editing: /home/axs/mail/xxxstuff.txt, ON LINE 1
>
> Pop11 was still running after that, so I could type 'ved' and continue with
> my edit!
Was SELINUX involved? In other messages (about different machines) you
wrote that you disabled SELINUX for build and then re-enabled it.
I am surprized that this worked at all, but with SELINUX active
you should expect ocasional crashes with message similar to the
one above. There is a way to configure SELINUX is such a way that
other programs are subject to all SELINUX checking, but Poplog
is an exception. Currently, this is best possibility if you
want SELINUX (I posted some links about configuring SELINUX
in the past).
If this is _not_ due to SELINUX, then it would indicate serious
problem well worth deeper investigation. I understand if you
do not want to investigate this, simply such issue my bite
in seemingly quite different situation.
>
> I did not understand what was happening. So I looked up the procedure that
> produced the message:
>
> ENTER sourcefile do_autosave_back
>
> That took me to this file
>
> $usepop/pop/lib/ved/ved_autosave.p
>
> But I was not able to understand what was going on. However, it had several
> tests of the value of the string vedautosave_preserve which I had somewhere
> set to true.
>
> ENTER ref vedautosave_preserve
>
> Took me to this entry in REF VEDVARS
>
> vedautosave_preserve -> item [variable]
> item -> vedautosave_preserve
> This variable, whose value should be a boolean, a string, an
> integer or a procedure, controls whether the automatic saving
> mechanism described in HELP * ved_autosave creates an initial
> EXTRA backup file for each file edited during the current
> session. It also controls how the saving is done. For full
> details see the HELP file.
>
> I then found that if I altered my vedinit file to replace
> vedautosave_preserve = true
>
> with
> vedautosave_preserve = '~~'
>
> The crashes stopped! (At least so far...).
>
> My first puzzle is why this happened on the new machine but not the old
> machine. The answer may just be as simple as some slip when copying files
> across.
>
> More importantly: is this messy system really needed?
>
> For now I'll just flag up the problem and leave it. Perhaps someone with
> experience of designing editors with autosave mechanisms could come up with
> a clean new specification.
AFAICS the change _directly_ should not help at all. So most
likely this changes code flow in such a way that avoids
executing failing code. Without way to reproduce problem
there is no way to find out what is the real reason.
But is is reasonable to expect that real problem is much
more general than saving files.
--
Waldek Hebisch
