topic error %SYSTEM-F-TBIT in Operating System - OpenVMS

error %SYSTEM-F-TBIT

Kelly Cox — Wed, 29 Nov 2006 13:33:45 GMT

%SYSTEM-F-TBIT
I get a stack dump with the above error.
I google'd the error, found nothing.
I tried ITRC search, found nothing.
I browsed the VMS manuals, including the C manuals...nothing.

This only crashes on my VAX, works fine on Alpha and Itanium. It's C code, common code on all platforms. The code has been running for 20 years on the VAX. I'm diff'ing code changes for the past year.

Could someone please point me towards documentation that would help explain the error?
tia...Kelly Cox

Re: error %SYSTEM-F-TBIT

Volker Halle — Wed, 29 Nov 2006 14:07:32 GMT

Kelly,

$ HELP/MESSAGE TBIT

TBIT, T-bit pending trap at PC='location', PSL='xxxxxxxx'

Facility: SYSTEM, System Services

Explanation: This message indicates an exception condition. It is usually
followed by a display of the condition arguments, registers,
and stack at the time of the exception.

User Action: Examine the PC and virtual address displayed in the message to
determine the instruction that caused the error.

Could you provide more information, like the actual printout ? Run it with /DEBUG and examine the instruction stream pointed to by the PC.

Normally, the T-Bit (in the PSL) is used by a debugger to enable stepping through a program instruction by instruction. When the T-Bit is set in the PSL, a trace trap occurs after execution of the next instruction.

Volker.

Re: error %SYSTEM-F-TBIT

Dave Gudewicz — Wed, 29 Nov 2006 14:08:20 GMT

Found this by searching on c.o.v.( circa
1992)

The TBIT is a bit in the PSL that causes the system to signal the TBIT
exception after every instruction. As you might guess, this is used by
the Debugger for a lot of operations.

For example, one way of stepping over a routine call is to:

1. Turn on the TBIT
2. Single step
3. Catch the TBIT exception
4. Look at the PC. Are we back in the calling routine (and
this isn't a recursive call)? If so, stop. If not, go
back to step 1 and continue.

(This glosses over a lot of detail)

The question to answer is: Does your program generate the TBIT exception
when run /nodebug, or does it only generate the problem when run with the
Debugger?

If the program generates the problem without the Debugger, then you're going
to have to look very carefully at your program. How is it setting the TBIT
bit in the PSL? Is it stomping on the stack and dirtying the TBIT bit in
a saved PSL? Are you doing something else that affects the stack in an
unusual way?

If the program only generates the TBIT fault in the Debugger, then it may be
a problem with your program or it may be a problem in the Debugger. I don't
know of any outstanding TBIT related problems reported against the Debugger,
so I'd start by assuming it's your program and running through the questions
in the previous paragraph. (If your program generates the TBIT even once
without the Debugger present, then it's definitely your program at fault.
Be forewarned - if your program generates spurious TBIT settings, it's
unlikely but possible to confuse the Debugger completely.)

If you believe that it's a Debugger problem after all your analysis is done,
please report the problem via the usual Digital problem reporting mechanisms.
We'll need to know the version of the Debugger and we'd really appreciate a
simple example that reliably reproduces the problem.

Re: error %SYSTEM-F-TBIT

Kelly Cox — Wed, 29 Nov 2006 14:39:06 GMT

%SYSTEM-F-TBIT, T-bit pending trap at PC=004DC49F, PSL=03C00030
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC

SHELF_CARD build_by_semester 5447 00000483 004DC49F
SHELF_CARD shelf_card 5334 000000BB 004DBFB3
CSM_MAIN curr_mgr_menu 12423 000003DD 004DA3E1
CSM_MAIN main 11535 000003CE 004D7F6E

The line of code is obvious, it is not new code. The dump happens with debug off. The error references a line that is a function call that does have new code in it. I'm trying to extract the code to a small code base that is not 10,000+ lines and see if the error persists. I'm sure it's program code, not the system. It's probably not odd that the same code runs fine on alpha and itanium.

Re: error %SYSTEM-F-TBIT

Ian Miller. — Wed, 29 Nov 2006 14:58:05 GMT

could it be something trampling on the stack?
Is there a function call above the line reported?

Re: error %SYSTEM-F-TBIT

Hein van den Heuvel — Wed, 29 Nov 2006 21:10:28 GMT

I'm with Ian. The T-bit trap is likely to be a secondary effect from the stack being overwritten. The function you mention is the victim, not the cause. Some local variable is being accessed out of bounds touching what becomes the PSL for a RET (RSB?). Maybe run with debugger and SET WATCH the stack location which holds the PSL? CC/LIST/MACHINE as needed. The actual problem is likely to be happening several (dozens of) lines before the failure point.

fwiw,
Hein.

Re: error %SYSTEM-F-TBIT

Volker Halle — Thu, 30 Nov 2006 01:34:50 GMT

Kelly,

SDA> eva/psl 03C00030
CMP TP FPD IS CURMOD PRVMOD IPL DV FU IV T N Z V C
0 0 0 0 USER USER 00 0 0 1 1 0 0 0 0

The PSL shown in the %SYSTEM-F-TBIT message actually does have the T-Bit set. Could you create a process dump and look at the instruction stream ?

$ SET PROC/DUMP
$ RUN your program
$ ANAL/PROC .DMP
DBG> EXA/INS 004DC49F
DBG> EXA/INS 004DC49F-10:004DC49F

You may need to try various values like -11, -10 etc. until you hit the correct instruction stream. VAX instructions are variable-length.

Volker.

Re: error %SYSTEM-F-TBIT

Kelly Cox — Sat, 02 Dec 2006 18:43:53 GMT

I agree, it is probably the PRECEDING function, especially as the preceding function is the only new code. If I choose an option that does not go into the function, it all works as in the past. It's a bit odd that the new function works fine on alpha and itanium. I've been busy on other priorities. Hopefully I can figure this out this weekend. I've just re-compiled this module with debug, but I've not used debug in 10 years. So time to open the vax debug manuals.

Thanks for the help so far. I've never looked directly at the 'stack', i'm not sure what i would be looking for.

Re: error %SYSTEM-F-TBIT

Volker Halle — Sun, 03 Dec 2006 05:24:59 GMT

Kelly,

you can't easily 'see' this problem with the debugger. But our theory is right ! Take this simple FORTRAN program:

call hallo
end
subroutine hallo
type *,'hallo'
end

Compile and link it with /DEBUG, run it:

DBG> set br hallo
DBG> go
break at routine HALLO
1: subroutine hallo
DBG> set language macro
DBG> exa/psl psl
HALLO\%PSL:
CMP TP FPD IS CURMOD PRVMOD IPL DV FU IV T N Z V C
0 0 0 0 USER USER 0 0 0 1 0 0 0 0 0

DBG> exa @fp+4 ! look at saved PSW in caller's frame
7FE94B44: 28000020
DBG> dep .=28000030 ! Set T-bit in saved PSW
DBG> g
hallo
%SYSTEM-F-TBIT, T-bit pending trap at PC=0000060C, PSL=03C00030
break on unhandled exception at Y$MAIN\%LINE 2+3
2: end
DBG> exa/ins 60c
Y$MAIN\%LINE 2+3: RET

So if you would just RUN/DEBUG your application program (without any need to compile or link it with debug or without even typing DBG> GO), you could examine the failing instruction:

DBG> SET LAN MAC
DBG> EXA/INS 004DC49F ! Failing PC
DBG> EXIT

If a RET is shown, you can be sure that the saved PSW on the stack has been overwritten.

You can then run the program with the debugger, set a breakpoint at the entry of the 'new function added'. Once you hit that breakpoint, issue a DBG> EXA @FP+4 and note the address and the value of the saved PSW.

You could try to set a watch-point on that location on the stack. Otherwise step through this program and continue looking look at @FP+4 until it's value changes.

Volker.

Re: error %SYSTEM-F-TBIT

Volker Halle — Sun, 03 Dec 2006 05:30:17 GMT

Kelly,

a slight correction:

DBG> SET LAN MAC
DBG> EXA/INS 004DC49F ! Failing PC
DBG> EXIT

If a RET is shown, you can be sure that the saved PSW on the stack has been overwritten.

The RET shown is just 'the next instruction' after the call to your new routine. In the example program, it's just the RET at the end of the program. So the instruction can be anything.

You can try to examine the previous instructions with:

DBG> EXA/INS -11;

Volker.

Re: error %SYSTEM-F-TBIT

Kelly Cox — Fri, 08 Dec 2006 09:19:05 GMT

I finally got the time to re-visit this problem. Being only VAX, it was not priority.
I compiled debug and then stepped through the new function and found the error. It was a simple text string that was modified to a new larger size for output, but not modified in the declaration. Of course it corrupted the stack.
I think it should have messed up on the Alpha and the Itanium.

Thanks for the help.

Re: error %SYSTEM-F-TBIT

Kelly Cox — Fri, 08 Dec 2006 09:19:48 GMT

I am closing thread.

Re: error %SYSTEM-F-TBIT

Jan van den Ende — Fri, 08 Dec 2006 13:14:01 GMT

So,

another victim of unrestrained null-terminated strings...

O boy, do I HATE those!

$ SET MODE RANT
$ DECK
Too bad VMS has succumbed to the habit of cryptogrammming /g/n/i/m/m/a/r/g/o/t/p/y/r/c in C with that error-promissing default string type! Well, at least it _DOES_ allow for decent descriptors, just a pity there is no way to dis-allow null-termination...
$EOD
$ SET MODE NORANT

fwiw

Proost.

Have one on me.

jpe