SCP directory copy not working after applying TCPIP ECO6

[Chris Warne_1]

Hi.

After applying the TCPIP ECO6 patch to Alphaservers running OpenVMS 7.3-2, attempting to SCP a directory from a remote system causes a stack dump. This happens regardless of whether the remote system is a Unix or VMS box, and even with a small text file. It also makes no difference whether or not keys are set up for password-less connection (where a password is required, the stack dump happens after the password is input). It happens both when doing a recursive copy of a named directory, or copying a directory file directly.
I've upgraded systems with ECO4 and ECO5 already installed with the same results. This worked perfectly on these system prior to the upgrade.

In Verbose mode, the following is displayed immediately before the stack dump (although the same is displayed when successfully copying files as well so it's probably not relevant):

tcpip$ssh_scp2.exe:SshFCRecurse/SSHFC_RECURSE.C:368: File is "raw", and it needs to be parsed.
tcpip$ssh_scp2.exe:SshFCRecurse/SSHFC_RECURSE.C:303: Received error `End of file' (1).


Below is an example of a successful copy of files from a directory, and a failure when trying to copy the same files using the directory name and the recursive option.

Has anyone else come across this problem?

$ scp username@nodename:testdir/*.* []

testfile.4 | 784B | 0.8 kB/s | TOC: 00:00:01 | 100%
testfile.3 | 784B | 0.8 kB/s | TOC: 00:00:01 | 100%
testfile.2 | 784B | 0.8 kB/s | TOC: 00:00:01 | 100%
testfile.1 | 784B | 0.8 kB/s | TOC: 00:00:01 | 100%

$ scp -r username@nodename:testdir []


%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000656C6982, PC=00000000001BAE0C, PS=0000001B

Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
00000000656C6982
00000000001BAE0C
000000000000001B

Register dump:
R0 = 0000000000000000 R1 = 0000000000000007 R2 = 0000000000035788
R3 = 000000000005EA46 R4 = 0000000000000000 R5 = 000000000000FFFE
R6 = 0000000000000001 R7 = 00000000006890B0 R8 = 00000000006890AC
R9 = 00000000006C84E8 R10 = 0000000000000002 R11 = 0000000000000000
R12 = 0000000000000001 R13 = 0000000000000001 R14 = 00000000002D28A4
R15 = 00000000006D55B0 R16 = 00000000656C6966 R17 = 0000000000000000
R18 = 0000000000035200 R19 = 0000000000000000 R20 = 00000000000AD680
R21 = 000000000053DF00 R22 = FFFFFFFF77773100 R23 = 0000004700000000
R24 = 0000000000000600 R25 = 0000000000000004 R26 = 00000000000FF434
R27 = 0000000000035788 R28 = FFFFFFFF80E02CC0 R29 = 000000007AE7CE40
SP = 000000007AE7CE30 PC = 00000000001BAE0C PS = 300000000000001B
%C-F-SIGCHLD, child process terminated or stopped

regards,

Chris

[Hoff]

This would appear to be a bug in TCP/IP Services (I assume) V5.4 circa ECO6.

Check around for any UCX* or TCPIP* images in SYS$SPECIFIC or other such staleness, and rung up HP.

If this SCP -r is central to your processing, might well be tempted to downgrade to ECO5 and see if that works.

I see reports of various problems in both ECO5 (FailSAFE) and ECO6 (BIND, Hosts).

There are reports of the availability of an ECO6+ version of TCPIP$IPC_SHR which fixes various problems.

Having any code tip over with an unhandled exception and a stackdump is itself a bug.

[Jan van den Ende]

Chris, (and Steve),

I regret to have to bring this up, but it seems to me, that the QA for TCPIP and its components is WAY below VMS standards.
This is about the umpteenth time that one thing or the other derails upon applying an IP ECO.
We are a little behind on patches, but if IP is concerned, I tend to not mind at all!
Is there some way that we (the user community) can get the IP people to comply with the stability we have come to expect from VMS?

Proost.

Have one on me.

jpe

[Hoff]

Feedback? Folks here chat with the IP business manager and with other senior HP staffers at the OpenVMS Bootcamp coming up in May, or at any of other similar events.

The other channel is through formal reports; calls to the support center.

The whole ITRC forums mechanism is two-edged: HP certainly benefits from having problems solved here, but then HP may or may not track problem areas that have been reported and/or resolved here. The reported problem gets fixed or gets worked-around and HP doesn't have to pay for the support call, but then the underlying problem or puzzlement or UI error or such (if there is one) may or may not get fixed.

[John Travell]

Has anyone actually looked at the exception ?
The code looks like it is trying to access offset 1C from R16, the contents of which look like a text string, "file". There is a high probability that R16 was supplied by the calling routine, which was most likely a JSR at 000FF430.
Note the last line, '%C-F-SIGCHLD'. I cannot say whether a 'set process/dump' will help, as I don't know if it will propagate to the 'child' (sub?) process.

Without access to either listings or source code I cannot take it further. If you have a contract, have you logged a case and had it escalated to engineering ?

JT:

[Chris Warne_1]

Thanks for the replies guys.

In reponse to Hoff, fortunately this problem came up during testing so there's no need to downgrade as we haven't upgraded yet (phew!).

It's interesting there emay be an RSH patch for ECO 6.

Anyway, I've logged a call with HP and I'll post the outcome here.

Chris

[Chris Warne_1]

Should have closed this earlier - sorry!

Below is a response I got from HP :

" ... I was able to reproduce your problem with a V7.3-2 V5.4 ECO 6 node and
the good news is this was already reported to TCPIP engineering
(including another issue with SFTP/SCP).

They have provided interim images to fix this issue, so I can supply you
these interim images.
Locally I've tested them and the ACCVIO is gone with these images.

Please note this isn't an official fix, if wanted, you'll have to wait
for ECO 7 of TCPIP V5.4
(no timeframe for release however ...) ... "