- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Interpreting Symbolic dump
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-27-2005 11:22 PM
07-27-2005 11:22 PM
Interpreting Symbolic dump
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-27-2005 11:36 PM
07-27-2005 11:36 PM
Re: Interpreting Symbolic dump
Please post (as an attachment) what you're getting. We might be able to help.
Regards,
Kris (aka Qkcl)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-27-2005 11:44 PM
07-27-2005 11:44 PM
Re: Interpreting Symbolic dump
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-27-2005 11:52 PM
07-27-2005 11:52 PM
Re: Interpreting Symbolic dump
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 12:50 AM
07-28-2005 12:50 AM
Re: Interpreting Symbolic dump
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 12:55 AM
07-28-2005 12:55 AM
Re: Interpreting Symbolic dump
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 01:11 AM
07-28-2005 01:11 AM
Re: Interpreting Symbolic dump
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 01:13 AM
07-28-2005 01:13 AM
Re: Interpreting Symbolic dump
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 01:17 AM
07-28-2005 01:17 AM
Re: Interpreting Symbolic dump
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 01:29 AM
07-28-2005 01:29 AM
Re: Interpreting Symbolic dump
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 01:44 AM
07-28-2005 01:44 AM
Re: Interpreting Symbolic dump
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 02:22 AM
07-28-2005 02:22 AM
Re: Interpreting Symbolic dump
$ 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 :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 02:25 AM
07-28-2005 02:25 AM
Re: Interpreting Symbolic dump
DBG>SET BREAK/EXCEPTION
DBG>GO
%DEBUG-I-EXITSTATUS, is '%SYSTEM-S-NORMAL, normal successful completion'
Antonio Vigliotti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 03:30 AM
07-28-2005 03:30 AM
Re: Interpreting Symbolic dump
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 03:35 AM
07-28-2005 03:35 AM
Re: Interpreting Symbolic dump
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 07:59 PM
07-28-2005 07:59 PM
Re: Interpreting Symbolic dump
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)).
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 08:09 PM
07-28-2005 08:09 PM
Re: Interpreting Symbolic dump
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
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 08:21 PM
07-28-2005 08:21 PM
Re: Interpreting Symbolic dump
>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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 09:12 PM
07-28-2005 09:12 PM
Re: Interpreting Symbolic dump
am using a variable inside a WHILE loop which is getting incremented but never initialized. Do think this should cause the error?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 09:18 PM
07-28-2005 09:18 PM
Re: Interpreting Symbolic dump
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 09:19 PM
07-28-2005 09:19 PM
Re: Interpreting Symbolic dump
It's still guessing. As Hein suggested, why not post a little snippet of the code (in the neighbourhood of the offending line of code).
On not initializing variables before using them, that's bad programming practice.
When compiled in debug mode, uninitialized variables usually contain zero; when compiled normal (optimized in some way), uninitialized variables can contain anything.
Regards,
Kris (aka Qkcl)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 09:41 PM
07-28-2005 09:41 PM
Re: Interpreting Symbolic dump
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=0000000A, PC =00003F3F, PSL=03C00000
break on unhandled exception at MY_FILE_READ\main\__17\%LINE 6144+24
6144: while(isalnum(rec_p.line_name[i][j])){
DBG> examine i
MY_FILE_READ\main\i: 0
DBG> examine j
MY_FILE_READ\main\i: 2293812
DBG>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 09:45 PM
07-28-2005 09:45 PM
Re: Interpreting Symbolic dump
One more thing to be aware of.
The compiler's optimizer may cause problems where you wouldn't expect them - but in 99% of all cases, it has nothing to do with the optimzer, but with programmers not obeying the code rules:
As an example:
A program is built using a commandprocedure, where all modules were copiled the same way: with, or without /NOOPTIMIZE.
When run, it crashed when it was built without /NOOPTIMIZE, but succeeded when compiled with the qualifier set. It was quite a job to find out which module caused it, but finally we found out it was a completely different one then where the program crashed. The cause was some piece of data that was constructed in another module, from an array that was one of it's parameter.
This caused the problem due to the way it was coded; the syntax was valid in itself, according the langauge specifications, so the compiler did not raise a warning or error on this. But we used it in a non-standard (quick and dirty) way, where some basic coding-rules in Pascal were violated, and that mislead the optimizer. It assumes you adhere to these rules, but if you don't, be prepared for some great times troubleshooting. (Program dumps, LIS and MAP files are indispensible!)
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 09:52 PM
07-28-2005 09:52 PM
Re: Interpreting Symbolic dump
6144: while(isalnum(rec_p.line_name[i][j])){
I'm assuming rec_p.line_name[i] is an array of characters.
Is the struct rec_p properly initialized? Also, the index j seems to be a bit big for indexing into the string.
But as I said earlier, still guessing.
Regards,
Kris (aka Qkcl)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2005 10:03 PM
07-28-2005 10:03 PM
Re: Interpreting Symbolic dump
and DBG> EXA/INS @PC ?
and the instruction stream:
DBG> SET LANG MACRO
DBG> EXA/INS @PC-40:@PC+10
The register contents:
DBG> EXA Rx ! for all registers referenced in failing instr.
Volker.