Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty command crashes CMS #98

Open
RossPatterson opened this issue Feb 28, 2025 · 3 comments
Open

Empty command crashes CMS #98

RossPatterson opened this issue Feb 28, 2025 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@RossPatterson
Copy link
Collaborator

Stefan Haubenthal wrote to the h390-vm group:

rexxtry
REXX interpreter running (CMS bREXX 1.0.1 Jul 5 2022)
Enter any valid REXX instruction... type EXIT to quit.
Rexxtry;
''
DMSITP143T PROTECTION EXCEPTION OCCURRED AT F20A02 IN SYSTEM ROUTINE EXEC, RE-IPL CMS.
CP ENTERED; DISABLED WAIT PSW '00020000 40F8B75E'

Confirmed in both releases 1.0.1 and 1.1.1.

@RossPatterson RossPatterson added the bug Something isn't working label Feb 28, 2025
@RossPatterson
Copy link
Collaborator Author

It looks like bREXX, GCCLIB, and CMS are all at fault here.

  • bREXX's (implied) ADDRESS instruction maybe shouldn't hand off an empty command to the CMS subcommand environment. But only maybe, because it isn't really Rexx's job to decide what the environment should do with a command, and whether an empty command is valid or not. For example, the EXECCOMM environment ignores the command text completely.
  • bREXX's HOSTCMD is generating an invalid extended parameter list (EPLIST) when the command is empty - EPLARGBG > EPLARGND, which ought to be impossible.
  • CMS's CMS subcommand environment (DMSCSF) attempts to just return to the caller if the command is empty, but it tests for that case incorrectly.
  • GCCLIB's CMSRUNTM is what's actually blowing up, when DMSCSF tries to run an exec called 'FFFFFFFFFFFFFFFF'x. I haven't figured out exactly why it's blowing up yet.

Since this is occurring in bREXX 1.0.1 (i.e., it's not a new bREXX 1.1.x bug), I'm not going to rush fixes. I expect to hit all three in one way or another.

@RossPatterson RossPatterson self-assigned this Mar 5, 2025
@polluks
Copy link

polluks commented Mar 7, 2025

By the way I was trying system("") in C (GCCLIB & PDPCLIB): It works!

@RossPatterson
Copy link
Collaborator Author

By the way I was trying system("") in C (GCCLIB & PDPCLIB): It works!

The C Standard Library's system() function does things differently. The GCCLIB code for system() calls an internal function that issues the command directly via SVC 202 - as if it was invoked via Rexx's ADDRESS COMMAND.

The PDPCLIB code (I can't find a repo that matches the code shipped in VM/CE 1.2 on the MAINTC 295 disk) doesn't even do that - it just returns RC=0 without issuing the command:

int system(const char *string)
{
#ifdef __OS2__
...
#endif
#ifdef __WIN32__
...
#endif
#ifdef __MSDOS__
...
#endif
#if defined(__MVS__)
...
#endif
 #if defined(__CMS__)
    /* not implemented yet */
    return (0);
#endif
}

In contrast, the Rexx ADDRESS instruction (which defaults to ADDRESS CMS in bREXX for VM/370) issues the command either via SVC 202 (for ADDRESS COMMAND) or via the CMS subcommand environment (implemented by DMSCSF), which checks for command abbreviations, CP commands and EXECs (depending upon the settings of the IMPCP and IMPEX flags), as well as the SVC 202 path. DMSCSF attempts to return 0 immediately if passed a empty command, but it does so by comparing the first 8-byte token with a single X'FF' (CLC CMNDLIST(8),=X'FF'), when the correct test is to check either the first byte (`CLI CMNDLIST,X'FF'), or all 8 (CLC CMNDLIST,=8X'FF'). Both are common techniques to recognized the "fence" at the end of a tokenized plist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants