On Fri, Aug 28, 2020 at 12:17:40AM +0100, Aaron Sloman wrote:
> I wrote on Mon Aug 17 22:23:10 BST 2020 (UPDATE below):
>
> > 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!
>
> UPDATE:
>
> I thought I had solved this problem by altering the value of
> vedautosave_preserve.
>
> But it now turns out that I was misled because after that mishap has
> occured while editing a file, if I continue editing it doesn't occur
> again in that session! I don't need to change any variable values.
>
> And altering vedautosave_preserve doesn't help as thought it did.
>
> I don't think this depends on selinux, as I have disabled it on this
> machine. Also I would expect selinux to abort the whole process, not cause
> its internal state to be changed from editing to not editing.
No, in many cases selinux simply refuses to perform system call
(like setting permisions) and the prgram goes on. Wrong
permision setting later cause faults that Poplog catches and
reports as above. Typically I would expect Poplog to abort
when it can not perform some critical operation, but if thing
that failed is not critical, then Poplog may continue working.
>
> I did not have that problem running the latest poplog on an older machine
> running fedora 29, only my new machine running f32.
>
> I guess I'll just have to go on looking for a pattern that I have not yet
> noticed.
As I wrote year ago, way to investigate this is to run Poplog inside
gdb:
gdb pop/pop/ved
At gdb prompt type
run
When ved crashes you should see info about where it crashed.
Again at gdb prompt type
info registers
and
disassemble 0x07FFFF7B12890-40,0x07FFFF7B12890+40
to see failing code. Note: 0x07FFFF7B12890 is program counter
of failing instruction. This may change from run to run,
gdb will tell you program counter of failing instruction.
Program counter is also shown in output of 'info registers',
as 'rip'.
--
Waldek Hebisch
