$ ON CONTROL activation crashes process with NOHANDLER error

[Olivier B]

Hello every body,

After patching OpenVMS 8.3 with some rating 1 & 2 patches (PCSI V2, UPDATE V6, SYS V8, RMS V7, FIBRE_SCSI V4, DECNET ECO2, TCPIP 5.6 ECO2, MANAGE V3, TRACE V1), I falldown in a strange process crash.

type tmp.com
$!------------------------------------------------------------------------------
$ delete /symb /all /local
$ delete /symb /all /global
$!ERR! on control then $ exit
$ pipe (show symb * | type sys$pipe /page)
$ inquire tmp
$ dir/dat sys$sysdevice:[*...]*.*;* /page
$ exit
$!------------------------------------------------------------------------------

if you spawn this proc, pressing CTRL/Y on DIR command ends the process.

if you delete "!ERR!" comment on the 4th line to activate the "ON ERROR" statement, pressing CTRL/Y on DIR command ends the process with :

Improperly handled condition, bad stack or no handler specified.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
0000000000000001
000000007AF6BAF4
0000000000000012

Register dump:
R0 = 0000000000000000 R1 = 0000000000000001 R2 = 0000000000000000
R3 = 000000007AFA6EDA R4 = 0000000000000000 R5 = 000000007FFCF800
R6 = 0000000000000000 R7 = 000000007AE7AA7C R8 = 000000007AE07FB0
R9 = 000000007FF9DDF0 R10 = 000000007FFA4F28 R11 = 000000007FFCDC18
R12 = 000000007FFCDA98 R13 = 000000007AEF7F70 R14 = 0000000000000000
R15 = 000000007AEF8680 R16 = 00000000144D4008 R17 = 0000000000000000
R18 = 0000000000000000 R19 = 0000000000000000 R20 = 0000000000000000
R21 = 0000000000000A88 R22 = 0000000000100000 R23 = 000000007FEABFA6
R24 = 000000007FFA6F40 R25 = 0000000000000000 R26 = 000000007AF5B320
R27 = 0000000000000010 R28 = 0000000000000001 R29 = 000000007FF9DDF0
SP = 000000007FF9CD9C PC = 000000007AF6BAF4 PS = 1C00000000000012

%DCL-S-RETURNED, control returned to process _FTA3:
%SYSTEM-F-NOHANDLER, no condition handler found


It could be on a DECTerm, a telnet from windows or a set host...
Spawn was just to prevent signon after each process crash...
Before these patches, it was working well...
It works well on other systems before these patches...

Any idea ???

[Hoff]

Crashes of most any sort are bad.

Something has romped on that stack.

Call HP support. They're going to want a look at this.

FWIW, that's a very nice concise reproducer and one of the better problem statements I've seen posted. But only HP has the source code to DCL, et al.

[Karl Rohwedder]

On my V8.3 alphasystem this error does not show up. I have all patches installed:

. @cnc_manager:check_fixes
VMS83A_ACC V1.0 : installed
VMS83A_AMACRO2K V1.0 : installed
VMS83A_CLIUTL V1.0 : installed
VMS83A_COPY V1.0 : installed
VMS83A_DCL V3.0 : installed
VMS83A_FIBRE_SCSI V4.0 : installed
VMS83A_LOGIN V1.0 : installed
VMS83A_MAILSHR V1.0 : installed
VMS83A_MANAGE V3.0 : installed
VMS83A_PCSI V2.0 : installed
VMS83A_RAMDISK V1.0 : installed
VMS83A_RMS V8.0 : installed
VMS83A_SMGRTL_MUP V1.0 : installed
VMS83A_SYS V9.0 : installed
VMS83A_TRACE V1.0 : installed
VMS83A_UPDATE V6.0 : installed

regards Kalle

[Wim Van den Wyngaert]

Did you reboot (as required for update v6) ?

Wim

[Olivier B]

Not after each patch, but after this group
PCSI-V0200, UPDATE-V0600, SYS-V0900, RMS-V0700, FIBRE_SCSI-V0400, DNVOSIECO02-V0803, TCPIP-V0506-9ECO2.

Here is the mistake ?

[Olivier B]

VMS83A_RMS V8.0 : installed
Not found on web patch page. What is the content ?

VMS83A_SMGRTL_MUP V1.0 : installed
arrived yesterday on web page. Could have a link to my problem. (stack corruption on SMG)

[Wim Van den Wyngaert]

So, you did boot at the end of the patching process ? Seems ok then.

Had undefined strange stuff once between install and reboot (7.3). Went away after the boot.

Wim

[Karl Rohwedder]

VMS83A_RMS V8.0:

has been put on hold, because it tries to set the VMS Versionstring and fails. A new patch (V9.0) was announced to be available real soon, but until now, nothing happened.

I appended the textfile for your information.

regards kalle

[Olivier B]

Hoff,
I opened the ticket to my support. I hope they would transmit...

Sorry for my english but I can't find meaning nor translation of abbreviations you use : "FWIW" and "et al."

VMS83A_SMGRTL_MUP installed but not solved.

I will wait for support before continuing to patch.

[Oswald Knoppers_1]

I always use http://www.acronymfinder.com/ for finding acronyms.

FWIW = For What It's Worth

:-)

Oswald

[Martin Vorlaender]

And FWIW: "et al" is latin, short for "Et Alii" which means "and others".

[Olivier B]

On Internet, I received 2 or 3 different answers.
Thank you Oswald and Martin, I feel less stupid now... :>

DCL.EXE from VMS83A_RMS-V0700.TXT (5-FEB-2008) seems to have the problem.

After VMS83A_DCL-V0300.TXT, DCL.EXE from 28-MAY-2008 seems to solve the problem.

[Hoff]

Why did I tell you to go to HP right away?

A stackdump from an OpenVMS tool or component is a bug.

This is an axiom.

Stackdump = unhandled error = bug

If you're patched to current, then unhandled errors and stackdumps should be reported to the vendor.

If you're not current on your patches and you're encountering an error, then get current before you proceed any further with your own debug and with any vendor call. This step eliminates the "known problems" (those with fixes released); it is a step that also makes for a much quicker path through the vendor support organization.

Unhandled errors can be the injection point at which a security attack is made.

Unhandled errors involving privileged code are particular targets for attacks. And DCL is most definitely privileged code.

Now as to whether this is a potential attack target or whether there's even remotely a vulnerability here is another discussion.

Assuming the stackdump is semi-valid, this appears to be executive-mode error. Yet more privileged than DCL. Which also ties into getting blown off the system. Which also means you should go look in the error log as (if this is the file system) then some system software logs (some of) its stackdumps there.

Regardless, stackdumps are indicative of code badness.

[Olivier B]

Answer from HP.
Bug is solved by VMS83A_DCL-V0300 but not commented in the release note. Update in progress...

Thank you.

I am reading the forum since a long time but I am always to late to solve...

Never imagine I had the answer when I wrote this thread...

[Olivier B]

Hoff, I agree with you.
I should have wait a little for support.
But investigation is interesting and if solution is the same as support...
In general, I am able to come back to previous steps, "ceinture et bretelles".

A la prochaine...