NOTES and Ctrl-C leads to TPU ACCVIO

[John Harney]

Greetings!

I have an Alpha running V8.3, with the latest patches as of a week ago.

When using NOTES (2.5, with the latest ECO), typing a simple ^C at the NOTES> prompt leads to an ACCVIO in "DECTPU."

This did not happen on V7.3-2. (We upgraded just two weeks ago to V8.3...)

Any thoughts? Thanks!!
\john

Notes> ^C

Fatal DECTPU internal error, please submit an SPR including:

1. A description of the actions that revealed the bug
2. The versions of DECTPU and the operating system you are running
3. Machine-readable media containing:
- The source files of your DECTPU section and command files
- Copies of the data files used during the session
- The keystroke journal file if one exists
4. Your terminal characteristics, if applicable
5. A description of the command used to invoke DECTPU

Shareable base: 7BC98884 Ident: DECTPU V3.2 2006-06-29 18:17
Updater base: 7C072034 Ident: DECTPU V3.2 2006-06-29 18:17
Updater file: TPU$CCTSHR

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000024, PC=00000000000B5384, PS=0000001B

[Robert Brooks_1]

Uh, submit an SPR :-)?

What sort of terminal (or emulator)?

It's reproduceable on my unpatched V8.3 Alpha system, using Powerterm 525 V5.6.

I'll poke around tomorrow (Thursday) to see who might want to take a look at this.

-- Rob

[John Harney]

SPR, QAR, PTR. QUIX? :)

At a minimum it happens with Powerterm, QVTnet, PuTTY, a SET HOST 0 and SSH LOCALHOST.

It's reproducible by all users, regardless of emulator.

Thank you for asking around!

\john

[Hoff]

That's ugly.

Try grabbing the V2.6 kit:

http://mvb.saic.com/freeware/freewarev70/notes_ft/

That's probably not going to cure this, but it's worth a shot.

The DCL ECO doesn't look relevant, but there's a DCL image lurking inside UPDATE V4, and (another?) one over in the SYS V3 (and in V4, too?) kit. ECO kits probably won't help, but HP support is likely to ask about this.

[John Harney]

Thanks for the pointer to the v2.6 NOTES kit. I might be able to try that next week. I agree; I don't think it's going to help with an ACCVIO in TPU's innards.

I do have the DEC AXPVMS VMS83A_UPDATE V4.0 ECO installed, and I read just today the SYS V4.0 kit contents, but they don't seem relevant; all solved issues reported in the kit .TXT file involve system crashes. That said, I will get the SYS V4 kit when I try the NOTES.

Much obliged.

\john

[Volker Halle]

John,

you could collect a little bit more information about the immeidate ACCVIO like this:

- invoke Notes in one terminal session
- invoke SDA in another terminal session
$ ANAL/SYS
SDA> SET PROC/IND=xxx ! set context to your process running notes
SDA> EXA/INS B5384 ! shows failing instruction

Which instruction ? Which module/shareable library and offset ? Is an ACCVIO at address 0x24 plausible with that instruction ?

I've tried it with Notes V2.5 on OpenVMS Alpha V8.2 - no problem. Just a message: 'Key CTRL_C_KEY currently has no definition'

Volker.

[John Harney]

SDA> ex/inst 0B5384
NOTES$SHARE+83384: LDL R0,#X000C(R0)
SDA>


Image Name Start End Type IMCB
--------------------------------------- -------- -------- ------------ --------
NOTES$MAIN 00010000 000301FF MAIN 7FF4E010
NOTES$SHARE 00032000 00112FFF GLBL SHR 7FF4EFA0
DECC$MSG 00146000 00149FFF MRGD SHR 7FF4EE70
...


R0 while sitting at the NOTES> prompt is an unrelated 00000FB2.


Image Identification Information

image name: "NOTES$SHARE"
image file identification: "NOTES V2.5"
link date/time: 6-DEC-1993 16:13:32.26
linker identification: "A10-62"


Thanks again to all!! It could indeed be that the new V2.6 notes will help.

\john

[Volker Halle]

John,

I'm actually running NOTES T2.5-1 on OpenVMS Alpha V8.2 (NOTES$SHR linked 22-APR-1994), so it seems worth to try the most recent version of NOTES (V2.6) as suggested by Hoff.

Volker.

[John Gillings]

John,

If you want to poke around and find out exactly what NOTES is asking TPU to do, try FAKE_RTL (latest version attached). Build a fake TPUSHR and maybe a fake NOTES$SHARE, turn on argument tracing and reproduce your error (in as few commands as possible, as those argument trace logs can get very large very quickly). Depending on what you find, it might be interesting to add LIBRTL and/or SMGSHR.