Conference turris::debug

1837.0. "Badstack, accvio from examin without /nosymbol??" by KERNEL::PULLEY (Come! while living waters flow) Mon Feb 10 1997 05:51

Hi Folks,

I've a customer, trying to do his own stack switching, using C, (but not
DECthreads).
In his multitasking, he uses the default stack if only one thread is
required, but his own stacks if there's more than one.
He doesn't have any trouble with just the one thread is used.

From the examin and examin/nosymbol results, he's not sure, nor am I, if
it's trying to understand things as a stack, and if it should.

Thanks for any comments/pointers/suggestions,
Steve.

$ server

	OpenVMS Alpha DEBUG Version V6.2-100

%DEBUG-I-INITIAL, language is C, module set to SERVER
%DEBUG-I-NOTATMAIN, type GO to get to start of main program

DBG> go
break at routine SERVER\main
 10656:    DAIS initialise("CalcSrv", OL);
DBG> set break S Calculator add
DBG> go
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000,
PC=004347A8, PS=0000001B
%DEBUG-I-INCMPSTACK, stack corrupted - attempting to continue
break at routine SERVER\S Calculator add
 10806:   Result=a+b;
DBG> set radix hex
DBG> examine 4347a8
SHARE$DEBUG+727A8: 0A000000
DBG>

show stack output omitted.

.
.
.

invocation block 1

  FP: 005A5670
  Procedure Descriptor (000010090):
    Flags:		3089
      KIND:		PDSC$K_KIND_FP_STACK (09)
      FP is Base Register
    Rsa Offset:         0028
    Signature Offset:   0000
    Entry Address:      SS_CALCULATOR_ADD
    Ireg Mask:          2000003C <R2,R3,R4,R5,FP>
      RA Saved @ 006A5698: 0000000000041274
      R2 Saved @ 006A56A0: 00000000000101B0
      R3 Saved @ 006A56A8: 0000000000502630
      R4 Saved @ 006A56B0: 0000000000000005
      R5 Saved @ 006A56B8: 0000000000502718
      FP Saved @ 006A56C0: 00000000006A56D0
    Free Mask:   00000000
    Size:        00000060

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000, 
PC=004347A8,PS=0000001B
%DEBUG-W-BADSTACK, stack corrupted - limited data available.
DBG>

      KIND:		PDSC$K_KIND_FP_STACK (09)
      FP is Base Register
    Rsa Offset:         0028
    Signature Offset:   0000
    Entry Address:      SS_CALCULATOR_ADD
    Ireg Mask:          2000003C <R2,R3,R4,R5,FP>
      RA Saved @ 006A5698: 0000000000041274
      R2 Saved @ 006A56A0: 00000000000101B0
      R3 Saved @ 006A56A8: 0000000000502630
      R4 Saved @ 006A56B0: 0000000000000005
      R5 Saved @ 006A56B8: 0000000000502718
      FP Saved @ 006A56C0: 00000000006A56D0
    Free Mask:   00000000
    Size:        00000060

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000, 
PC=004347A8,PS=0000001B
%DEBUG-W-BADSTACK, stack corrupted - limited data available.

DBG> examine 6a5670
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000, 
PC=004347A8,PS=0000001B
%DEBUG-W-BADSTACK, stack corrupted - limited data available.
DBG> exam/nosymb 6A5670
006A5670: 00010090
DBG>

>I've a customer, trying to do his own stack switching, using C, (but not
>DECthreads).

Naughty, naughty...;-)  Seriously though, DECthreads is good (and getting
better all the time).  Debug has special hooks and visibility into DECthreads
and their threads....and soon into their mutexes and condition variables.
So...why must they go their own way with their own threads package?

Nonetheless...

> From the examin and examin/nosymbol results, he's not sure, nor am I, if
> it's trying to understand things as a stack, and if it should.

Debug will symbolize addresses first and then walk the stack for most
examines to check for matching frame local symbols and scoping etc.  So, it
is not surprising to see BADSTACK warnings on symbolic examines.

I suspect that the problem here is with how he/she is terminating his thread
stacks...or perhaps how, if he/she is, linking them together to his main
thread stack.  Note that, I believe, a valid stack terminates with a dummy
frame whose FP is 0...NOT with a real frame whose saved FP is 0.

Note that you can "verify" correct stacks yourself, i.e. without the debugger,
by writing a test stack walk routine that uses the same functions that the
debugger depends on.  That is, write a simple routine that walks the stack
with LIBRTL's LIB$GET_CURRENT_INVO_CONTEXT and LIB$GET_PREVIOUS_INVO_CONTEXT.
Check the status returned by LIB$GET_PREVIOUS_INVO_CONTEXT.  A status return
of 0 or 3 indicate a problem.  See the OpenVMS Calling Standard for more
details.

Lon