Operating System - OpenVMS
1748181 Members
3733 Online
108759 Solutions
New Discussion

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

 
Jansen_8
Regular Advisor

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

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
Regular Advisor

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

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
Honored Contributor

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

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
Regular Advisor

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

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
Honored Contributor

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

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.