| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5861.1 | anybody out there ? | ZPOVC::SINSPS | | Thu Feb 17 1994 02:11 | 1 |
|
|
| 5861.2 | can try checking if your MM is correct | TAEC::FLAUW | Marc Flauw, CEM Technical Office, VBO | Thu Feb 17 1994 06:01 | 21 |
| re: .0
I was hoping that a more experience DECmcc/VMS guru would answer your question,
as it has been a long time since I have used DECmcc on VMS. (we are working with
Ultrix and OSF/1).
If my memory serves me well, this message might come from the exception handler
to signal a problem loading the management module. I don't remember enough
infortunately to know if it can also be generated in other cases.
I would check first with the management module that you are trying to debug,
like is there a correct executable, readable, compiled and linked with debug,
are the init, probe and log entry points correctly defined with the names
corresponding to the MM name, ...
Sorry not to be able to help you more,
Best regards,
Marc.
|
| 5861.3 | lib$signal(SS$_DEBUG) missing ? | TAEC::LAVILLAT | | Mon Feb 21 1994 05:51 | 15 |
|
If I remember well VMS (so long time ago !), you have to enter
the debugger, to place a few instructions in your code like :
LIB$SIGNAL(SS$_DEBUG);
If this line is missing, you will have this famous 'revectoring conflict'
message.
I guess (hope) this is documented in the MCC MM programing guide.
Regards.
Pierre.
|
| 5861.4 | | ATYISA::ROGGEBAND | Unplugged | Mon Feb 21 1994 08:06 | 12 |
| I remember getting this message when I linked my MM's with the /DEBUG
option and then started up the FCL PM without the /DEBUG switch.
I don't remember wether you should link with or without /DEBUG to use
the TBD. Just check if what you did matches what the TBD expects, and
then relink your MM.
Regards,
Philippe.
|
| 5861.5 | Not Harmful, just ugly | SCCA::dave | Ahh, but fortunately, I have the key to escape reality. | Mon Feb 21 1994 10:56 | 5 |
| Philippe has it right. The message is caused by running a /DEBUG MM without the /DEBUG
switch. It is caused by multiple efforts to re-vector the QIO's that are used so that CMA can catch
them and re-schedule another thread.
The output is not harmful, just ugly.
|
| 5861.6 | additional infos | ZPOV05::SINSPS | | Fri Feb 25 1994 08:34 | 45 |
| Here's what the customer did and outcome with error messages :-
$ mana/tool/test
MCC_TBD> show version
MCC_TBD Version V1.3.0
MCC_TBD> break
%MCC-E-REVECTCONFLICT, revectoring conflict
-SYSTEM-F-DEBUG, command interpreter debugger signal at PC=001038B8,
PSL=03C00000
%TRACE-E-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
001038B8 001038B8
----- above condition handler called with exception 0000046C:
%SYSTEM-F-DEBUG, command interpreter debugger signal at PC=001E869F,
PSL=03C00000
----- end of exception message
001E869F 001E869F
001E6423 001E6423
001E750F 001E750F
000D6762 000D6762
MCC_MAIN main 7724 00000189 00002035
0000596F 0000596F
MCC_KERNEL_INIT MCC_KERNEL_INITIALIZE 163 00000027 000059A3
MCC_TBD> 0000594A 0000594A
$mana/tool/test/debug
VAX DEBUG Version V5.5-021
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual
address=180093A0, PC=80000010, PSL=03C00004
%DEBUG-E-LASTCHANCE, stack exception handlers lost, re-initializing
stack
With the above error messages, would they affect the usage/operation
of the TEST BAD DRIVER. How to overcome them ?
I'm new to this product, thanks.
- LEH
|
| 5861.7 | some input. | MCDOUG::doug | Imagine whirled peas. | Fri Feb 25 1994 15:43 | 30 |
| I never really tried dropping into the debugger for any AMs from the TBD -- I
did that from MCC with the /DEBUG option. I only ever used TBD to
troublshoot dispatcher problems (that's what TBD is most appropriate for,
IMO).
Why do they want to use TBD to drop into the debugger, instead of doing it
from within MCC?
I can't see how the debugger will know where "land" you on the BREAK command,
unless you've given the TBD enough info to know WHERE to dispatch in your AM
code. (E.g. deposit verb 1, deposit attr 99, etc.)
These things come to mind:
1. Don't use the /DEBUG qualifier when starting the TBD -- debugger should be
activated *automatically* with TBD.
2. Make certain that the MM was compiled and linked with DEUBG enabled.
3. Before doing a BREAK in TBD, ENROLL the AM in the TBD (with the ENROLL
command).
4. Using MCC with the /debug option, what do you see when you enroll the MM
(built with debug) example:
$ MANA/ENT/DEBUG
MCC> enroll mcc_foo_am
MCC> show foo bar all attr
/doug
|