topic Re: Interpreting Symbolic dump in Operating System - OpenVMS

Interpreting Symbolic dump

ram_47 — Thu, 28 Jul 2005 06:22:54 GMT

When I execute my program I am see a symbolic dump. Is there a way to interpret the same

Re: Interpreting Symbolic dump

Kris Clippeleyr — Thu, 28 Jul 2005 06:36:49 GMT

Ram,

Please post (as an attachment) what you're getting. We might be able to help.

Regards,
Kris (aka Qkcl)

Re: Interpreting Symbolic dump

ram_47 — Thu, 28 Jul 2005 06:44:32 GMT

Dump attached.

Re: Interpreting Symbolic dump

Kris Clippeleyr — Thu, 28 Jul 2005 06:52:40 GMT

Hi Ram,

It looks like your program wants to read from address 0000000A (which under VMS is strictly forbidden).
This is clearly a programming error. Did you by any chance pass something to a routine by value instead of by reference? It looks like that to me.

Hope this helps,
Kris (aka Qkcl)

Re: Interpreting Symbolic dump

ram_47 — Thu, 28 Jul 2005 07:50:13 GMT

I have checked the code but i dont see anything of that sort.

Re: Interpreting Symbolic dump

Kris Clippeleyr — Thu, 28 Jul 2005 07:55:51 GMT

Ram,

If it's possible, could you post the source of your program?
Also, you can build a debug version of your program ( CC/NOOPT/DEBUG & LINK/DEBUG ).
And if you run your program then, the symbolic debugger comes along, and you can step through the program line by line and see where it goes wrong.

Kris (aka Qkcl)

Re: Interpreting Symbolic dump

ram_47 — Thu, 28 Jul 2005 08:11:28 GMT

I would have liked to attach the code but I cannot do that. But I shall certainly try creating the debug script.

Re: Interpreting Symbolic dump

Ian Miller. — Thu, 28 Jul 2005 08:13:59 GMT

If running the program with the VMS Debugger then SET BRE/EXCEPTION will stop and allow you to see where in your program is ACCVIO occours.

Re: Interpreting Symbolic dump

ram_47 — Thu, 28 Jul 2005 08:17:26 GMT

am at the DBG> prompt. how do I debug from here?

Re: Interpreting Symbolic dump

ram_47 — Thu, 28 Jul 2005 08:29:03 GMT

where do i give SET BRE/EXCEPTION command?

Re: Interpreting Symbolic dump

Kris Clippeleyr — Thu, 28 Jul 2005 08:44:49 GMT

Hi Ram,

A the DBG> prompt, you first type a GO to reach the "main" function. Then, type SET BREAK/EXCEPTION, and GO again.
This will cause the debugger to stop executing your program when an exception occurs. If this happens, the DBG> prompt returns, and then you can type SET MODE SCREEN,and you'll see where the error occured.

Regards,
Kris (aka Qkcl)

Re: Interpreting Symbolic dump

ram_47 — Thu, 28 Jul 2005 09:22:40 GMT

Here at the steps and messages that I have got

$ run
DBG>GO
%DEBUG-I-EXITSTATUS, is '%SYSTEM-S-NORMAL, normal successful completion'
DBG>SET BREAK/EXCEPTION
DBG>GO
%DEBUG-E-BADSTARTPC, cannot access start PC = 00000000
DBG>SET MODE SCREEN
- SRC -scroll-source--
%DEBUG-W-SCRNOSRCLIN, no source line for address 00000000 for display in SRC
- OUT -output---
- PROMPT -error-program-prompt--

Looks like it is not going to show me the error source :)

Re: Interpreting Symbolic dump

Antoniov. — Thu, 28 Jul 2005 09:25:27 GMT

$ run
DBG>SET BREAK/EXCEPTION
DBG>GO
%DEBUG-I-EXITSTATUS, is '%SYSTEM-S-NORMAL, normal successful completion'

Antonio Vigliotti

Re: Interpreting Symbolic dump

Volker Halle — Thu, 28 Jul 2005 10:30:53 GMT

Ram,

DBG>GO
%DEBUG-I-EXITSTATUS, is '%SYSTEM-S-NORMAL, normal successful completion'

your program did NOT cause an ACCVIO this time - it successfully ran until completion.

The original access violation happened in MY_FILE_READ in line 6232. If you issue a SET PROC/DUMP before running your original program, you will get a process dump written (imagename.DMP), which you can analyze with ANAL/PROCESS. On the DBG> prompt, issue DBG> EXA/INS @PC to see the failing machine code instruction.

Volker.

Re: Interpreting Symbolic dump

ram_47 — Thu, 28 Jul 2005 10:35:43 GMT

strange things happening here. initially i used to get a dump on the screen but since i started debugging the program the dump just disappeared. and now without the debug my program runs fine :-)

i think at some point i changed some code. but not sure of the change :)

anyways, i'll keep a watch on my program and see.

Re: Interpreting Symbolic dump

Willem Grooters — Fri, 29 Jul 2005 02:59:05 GMT

For interactive debugging, with all facilities the VMS debugger has (viewing code, knowing symbols) you need to compile and link with the /DEBUG qualifier. For basic debug, I should use the /NOOPTIMIZE qualifier as well.
Compile with /LIST, it gives yoy the source listing; link with /MAP/FULL that will give you the full image map, which can be very usefull (for final builds, I would strongly suggest both of these, since that will come out exteremely handy if the program crashes and you have to analyze the process dump).
If you make this your standard procedure, you never can go wrong ;-)

Ok, your dump and traceback:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000A, PC=00003F3F, PSL=03C00000

Volker already explained that.
One reason could be you expect to read a value, but actually access an address; probably in an assignment, or in passing a parameter to a C-function, or one of your own.

%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC

MY_FILE_READ main 6232 000001C7 00003F3F

The problem is found in the main() of your program (MY_FILE_READ.C) at line 6232.

Now you take your listing and look for this line. One of the variables on that line will have a value of 10 (0000000A in hex), but you will need to access the ADDRESS of that var, not the value.

Next, to analyze (assuming you built the program like above):

$ RUN MY_FILE_READ
DBG> SET BREAK %LINE 6232
DBG> GO

and on breakpoint, examine source and each var in it, before excuting that line.

(here, it is essential you compile with /NOOPTIMIZE, to force the processor to execute the code in-line, not out-of-order (which is the default method)).

Re: Interpreting Symbolic dump

Willem Grooters — Fri, 29 Jul 2005 03:09:32 GMT

Sorry, just the other way around ;-) Read this as:

One reason could be you expect to access an address but actually read an value.

Some additional hint:
DBG> EXAMINE wiill give you the CONTENTS on the variable. DBG> EXAMINE @ will use the contents of as the address and display the contents at that address. Consider you specified in your program: int a ... a = 10; and at the breakpoint, you give: DBG> EXAMINE a you will get 10, and DBG> EXAMINE @a will give something stating you accessed a location you're not allowed to: ACCVIO, as in your crash. Hope this explains. Willem

Re: Interpreting Symbolic dump

Hein van den Heuvel — Fri, 29 Jul 2005 03:21:56 GMT

>I would have liked to attach the code but I cannot do that.
> But I shall certainly try creating the debug script.

Just a little code around that reported line 6232 should be a good start

One good address for that address 10 could be that the source line 6232 contains a reference to a field with offset 10 within a structure where the pointer to the structure was not valid.
Something like

struct detail {char name[10], flag, ...} detail_p;
struct {long id; struct detail *detail_p; ...} control
:
detail_p = control.detail_p; /* what if NULL? */
x = detail_p->x;
:

fwiw,
Hein.

Re: Interpreting Symbolic dump

ram_47 — Fri, 29 Jul 2005 04:12:04 GMT

ok, here i am again. this time i managed to reproduce the error. yesterday after the error what i did was i initialized some of my variables in the function. so that had eliminated the error. and today to reproduce the error i have removed the variable initialization part and i get the error again.

am using a variable inside a WHILE loop which is getting incremented but never initialized. Do think this should cause the error?

Re: Interpreting Symbolic dump

Volker Halle — Fri, 29 Jul 2005 04:18:12 GMT

Ram,

why speculate ?!

Show us the failure (traceback info) and the associated source code line. Also show us the failing machine instruction (DBG> EXA/INS @PC) and the values of the registers involved in that instruction.

Volker.