Question about the 497.1-day-uptime bug.

Volker Halle · *nix forums beginner Joined: 29 Jul 2005 Posts: 33

AEF,

it is quite likely, that V6.1 could also exhibit this problem.

The 497.1 fix done to [SYS]WRTMFYPAG is dated MAY-1998. The most recent
available WORKING_SET_MANAGEMENT.EXE for V6.1 is dated APR-1996 (from
VAXSYS16_061).

And the code in V6.1 is the same, so the 'bug' is in there as well and
probably also in earlier versions.

Volker.

AEF · *nix forums Guru Joined: 27 Jul 2005 Posts: 516

JF Mezei wrote:

JF Mezei · *nix forums Guru Joined: 21 Jul 2005 Posts: 2556

AEF wrote:

AEF · *nix forums Guru Joined: 27 Jul 2005 Posts: 516

Hello!

In VAX/VMS V6.2, there is the 497.1-day-uptime bug. Does anyone happen
to know if V6.1 also has this bug? I looked on the Web but couldn't
find anything. A description of the bug follows. Thanks!

Problems addressed in VAXSYSA02_062 kit

o If a system has been up for 497.1 days without rebooting, the
system cell EXE$GL_ABSTIM_TICS (number of 10 millisecond tics
since boot) will overflow. This problem can cause some
processes to remain indefinitely in the RWMPB or COMO
scheduling state. Furthermore, candidate processes for Virtual
Balance Set Slot (VBSS) selection can be missed.

Code using the EXE$GL_ABSTIM_TICS cell to time other activity
could get stuck if a reference counter is large (FFFFxxxx) and
the EXE$GL_ABSTIM_TICS value is low due to the overflow
(0000xxxx). Most such checks compare to see if the number of
tics is larger than the reference value, i.e. has the event
come due?

Google