- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: 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
Discussions
Discussions
Forums
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
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-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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-28-2005 10:14 PM
тАО07-28-2005 10:14 PM
Re: Interpreting Symbolic dump
You said:
[I] am using a variable inside a WHILE loop which is getting incremented but never initialized. Do think this should cause the error?
It certainly could. You also might not be able to reproduce the problem every time. As mentioned by Kris above, there's no telling what value an uninitialized variable might have.
Can you provide a bit more code for us? It might be helpful to see how the uninitialized variable is declared, its most recent use before the error, and the declaration of any struct object(s) it might be indexing within.
Also, where you have
DBG> go
%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>
Does the value of 2293812 look reasonable for j given the size of whatever line_name[i] points to?
Could you then give this command and see what happens:
DBG> examine rec_p.line_name[i][j]
Given the code you gave us, I wouldn't expect the values shown for i and j to give an accvio against address 10. But maybe we'll learn a little more.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-28-2005 10:44 PM
тАО07-28-2005 10:44 PM
Re: Interpreting Symbolic dump
what i'll do is write a short program on the lines of my original code so that i could share with you guys. i should be able to reproduce that error again.
and i must say this forum has been very helpful in resolving my issues, thanks a bunch. i hope to get such support in future too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-09-2005 11:29 PM
тАО08-09-2005 11:29 PM
Re: Interpreting Symbolic dump
DBG> set break/exception
DBG> go
break at routine MY_FILE_READ\main
14600: int record_no = 0;
DBG> examine record_no
MY_FILE_READ\main\record_no: 2064480377
DBG>
could someone tell me what is going wrong here?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-09-2005 11:44 PM
тАО08-09-2005 11:44 PM
Re: Interpreting Symbolic dump
this number looks like P1 space address:
SDA> eva ^d2064480377
Hex = 00000000.7B0D7879 Decimal = 2064480377
There is some bug in your program. Start with DBG> EXA/INS @PC-10:@PC to find the failing instruction stream.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-10-2005 12:32 AM
тАО08-10-2005 12:32 AM
Re: Interpreting Symbolic dump
> run my_file_read
DBG> EXA/INS @PC-10:@PC
%DEBUG-E-NOACCESSR, no read access to address 000000000002FFF6
DBG>
if i start off with GO and then EXA/INS, i get output as below
> run my_file_read
DBG> go
break at routine TQS_EXTRACTOR\main
14600: int record_no = 0;
DBG> exa/ins @pc-10:@pc
TQS_EXTRACTOR\main\%LINE 14592+42:
TQS_EXTRACTOR\main\%LINE 14592+46:
TQS_EXTRACTOR\main\%LINE 14592+50:
DBG>