%SYSTEM-?-ILLPAGCNT : what does it tell me?

[Jansen_8]

Hi all,

I'm trying to port a package (actually libarchive) to OpenVMS. The compilation works fine, but when running the test program that comes with the package it stops with the message:

    %SYSTEM-?-ILLPAGCNT, illegal page count parameter

The error does not always occur in the same part of the test program, but seems to depend on the actual machine and load.

What does this message try to tell me?

In what direction should I look for a solution?

I'm compiling with DECC 7.3-10 on OpenVMS 8.4 (AXP) and DECC7.3-20 on OpenVMS 8.4 (IA64)

                    Regards

                            Jouk

[Maurizio De Tommaso_]

ILLPAGCNT,         illegal page count parameter

Facility:                SYSTEM, System Services

Explanation:      The number of pages specified for an expand or control region
                                request is less than 1 or it would cause the program or
                                control region to exceed its maximum size.

User Action:       Check for a programming error; verify the number of pages
                               specified for the service call.

[Richard Brodie_1]

" %SYSTEM-?-ILLPAGCNT, illegal page count parameter

What does this message try to tell me?"

The important part is the ?, which tells you that the severity bits of the status aren't valid. In that case, I would assume that the whole thing is likely a garbage status value.

The question is how you came to be returning that value - is it just exiting with a random status, or data corruption somewhere? Unfortunately, you are likely to have to do some digging in the code to find out.

[Craig A Berry]

It means the test is exiting with a value of 254:

$ exit 254
%SYSTEM-?-ILLPAGCNT, illegal page count parameter

It's unlikely to be a random status or data corruption, though the latter is possible.  It's more likely a valid POSIX exit status that means something completely different on VMS. One clue is that POSIX only provides for statuses in the range 0-255, so something in that range has a good chance of being one of those.

Try compiling with /MAIN=POSIX_EXIT and see if that behaves any better.

[H.Becker]

>>> What does this message try to tell me?

That your program returned the numbers 254 to DCL. Maybe  you can find that number in the source as an exit code. Which means there is a call to exit with that value or a return in your main program.  But such an unexpected VMS status was not unusual in older versions of the C compiler: without an explicit return or exit call, the last value or return code of the last function called in main was return to DCL. Nowadays with  all the nice wrappers around main it should only happen if you don't have a  C main as in

$ cre x.c
int i;f(){i=254;}
^Z
$ pipe cc x && link x       
$ r x
%SYSTEM-?-ILLPAGCNT, illegal page count parameter
$ 

[Hoff]

It's probably time to use the VMS debugger, or to use breadcrumb debugging if you must.  The debugger will be far more efficient in general, as you can compile the code with /DEBUG /NOOPTIMIZE and then link with /DEBUG, then step through the source code looking for the error using the debugger, and with access to the variables using commands such as EXAMINE.  The latter approach is quite common among folks that prefer to avoid debuggers and other newfangled tools.

[Jansen_8]

Just running the debugger without break points did not reveal the point of error. It just stopped and did not tell what code was used last.

Since the code contains a lot of loops and tests that succeed I tried to pinpoint the probelematic part by adding some printf statements. I was not able to realy pinpoint the location yet, since it became more ugly : adding the printf near the point where it crashed resulted in a crash earlier in the code, that did run correctly previously.

And yes I detected the code exit(254) in the source, but I could not prove that it was reached (either by debugging and by a printf statement.

Seems I have to find time to dig deeper into this code.

Thanks for the tips.

                    Jouk

[Hoff]

You're porting libarchive, a presumably-archival-related package from {somewhere}.

You're using OpenVMS Alpha V8.4, and OpenVMS I64 V8.4.

You're getting a return or exit status value of 254 from {somewhere}.

Unfortunately, here's what this return status and the assoociated (bogus) error message tells you:  nothing.  Utterly nothing.  It's bogus. 

254 is not a legitmate VMS return code.   254 might be a legitimate return from some (presumably) C routine that returns non-zero as success, or it might be some left-over junk that gets returned from somewhere (and that the Linux didn't care about) when the tool exits, or it could be a failure status from within the tool.   The constants in errno.h don't have a value anywhere near 254, so that's not likely involved.  Or some sort of a compiler or build error, or a latent error in the source code.  

Only by looking at the source code will the meaning of 254 become clear.   If it even has any meaning.

Your choices are to use the debugging tools — the debugger does have breakpoints and breakpoints can be used here, and the debugger can also even be programmed to check for and wait for various conditions — or use printf commands and old-school breadcrumb debugging, or you can post up your code and your port (so far) and hope that somebody else will debug this and/or port this for you.  

Barring some rather extreme and unlikely luck — that you get an answer from somebody that's already ported libarchive and saw this 254 return or exit code — there's no answer here, short of looking at the source code.

If you want to continue with this and get some further help here, please post up the repository for this source code — maybe downloaded from the http://libarchive.org site? — and the sequence that you're using to build and test this, and where you're seeing the 254 value from, so that somebody here doesn't have to hunt around and port and otherwise spend a morning getting to where the 254 value can be observed, and the source code debugging started.

[H.Becker]

First thing in main, declare a VMS exit handler.  There are at least a few examples on the net, how to do that. Compile, link and run with debug, set a breakpoint on the exit handler and do a show call.

 module name    routine name     line           rel PC           abs PC
*XIT            exit_handler    24421       0000000000000024 0000000000030024
                                            FFFFFFFF80086198 FFFFFFFF80086198
 SHARE$SYS$SSISHR                           0000000000011790 000000000048B790
 SHARE$SYS$SSISHR                           0000000000010CC8 000000000048ACC8
 SHARE$SYS$SSISHR                           0000000000011884 000000000048B884
*XIT            g               24451       00000000000001F4 00000000000301F4
*XIT            f               24447       00000000000001B4 00000000000301B4
*XIT            main            24439       000000000000017C 000000000003017C
*XIT            __main          24429       0000000000000110 0000000000030110
                                            FFFFFFFF80385D54 FFFFFFFF80385D54


$ sea *.lis 24451/wind=(1,0)/noheader
      1   24450 int g() {
      1   24451         exit (254);
$ 

[Hoff]

Good idea.   Since this is C code and easier than messing around with a VMS handler is the C atexit declaration:

         #include  <stdlib.h>

         int atexit  (void (*func) (void));

Also, these debugger commands might get you closer to the error...

DBG> SET BREAK /RETURN 

or 

DBG> SET BREAK /TERMINATING 

Or set a breakpoint in the middle of the main block of code, and GO.   If things don't stop, set the breakpoint in the middle of the remaining code, and GO.  If they stop, move the breakpoint earlier.

[Jansen_8]

All info on the package can be found at:

http://http://nchrem.tnw.tudelft.nl/openvms/software2.html#LIBARCHIVE

I even tried to change the exit(254) statements in any other number, but still got the same error -> it stops somewhere else.

[Jansen_8]

The method of setting breakpoints "half-way" works for sequential code. Here it crashes somewhere in a inner-loop that has previously runned without problems 100's of times.

[Hoff]

If it's triggering mid-way through some large loop, then that's probably the bug.  (Yeah; there's my hammer-lock on the obvious, again.)

It does not matter how many thousands or millions of times a loop executes successfully nor how many weeks or months a program might run, run-time bugs and corruptions and quota leaks can and variously do arise.

Yes, long loops are more of a hassle to debug than straight-line code, but the debugger can be programmed to wait some number of loop iterations before returning to the user.   The same binary search technique through faulty sequential logic is entirely possible using debugger conditional commands with some loop index variable or whichever local variable is going out-of-spec, if that's known.  That can involve printfs in the loop looking at the range of the variables (or probably easier to rummage through, fprintfs to some log file), or program the debugger to examine and/or log those same variables for you, or switch the local loop variables over to extern scope so that the values can be visible from within the scope of the atexit.

Again, if you've got the atexit or the related exit triggering, then check the variables (those that are still in scope) for any out-of-range values, check the process quotas, and work back up the stack from the crash for the trigger, and — probably most importantly — examine exactly what the loop is doing.  Look for the conditions where it might exit, either intentionally or due to some coding error.   Look for a mishandled end of file (EOF) or loop exit condition, or code that is allocating but not releasing temporary memory, etc.

As can be inferred, if you want somebody here to look at this bug for you, please provide the command(s) or the test case(s) or some sort of a reproducer — some sequence to get from the download and the build directly to the bug, so that folks are not groping around just trying to find the bug.   Also please consider posting some details of what you've found so far, including which loop in the code is apparently tipping over. 

[Jansen_8]

Thanks for all the reaction. The main thing I already learned

  - it is error code 254

  - The message probably tells me nothing.

When I find time I'll continue debugging the problem.

[Craig A Berry]

Have you actually tried CC/MAIN=POSIX_EXIT as I suggested before?  It is entirely possible that there is no bug or problem except for conflicting notions of what  an exit status means.  The fact that modifying the exit(254) literals doesn't change anything also doesn't mean much.  Test suites typically run by spawning off a subprocess for each test.  If the subprocess is brought down by a signal (which might well be intentional), the exit status can be concocted from the killing signal, for example.