Operating System - OpenVMS
1754020 Members
7391 Online
108811 Solutions
New Discussion юеВ

Re: Interpreting Symbolic dump

 
Kris Clippeleyr
Honored Contributor

Re: Interpreting Symbolic dump

Ram,

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)
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
ram_47
Frequent Advisor

Re: Interpreting Symbolic dump

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>
Willem Grooters
Honored Contributor

Re: Interpreting Symbolic dump

ram,

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!)
Willem Grooters
OpenVMS Developer & System Manager
Kris Clippeleyr
Honored Contributor

Re: Interpreting Symbolic dump

Ram,


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)
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Volker Halle
Honored Contributor

Re: Interpreting Symbolic dump

Ram,

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.
Galen Tackett
Valued Contributor

Re: Interpreting Symbolic dump

Ram,

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.
ram_47
Frequent Advisor

Re: Interpreting Symbolic dump

j is declared as int. As per Kris since it was not initialized it has taken value 2293812. and i forgot to run EXA/INS @PC.

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.
ram_47
Frequent Advisor

Re: Interpreting Symbolic dump

> run my_file_read
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?
Volker Halle
Honored Contributor

Re: Interpreting Symbolic dump

Ram,

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.
ram_47
Frequent Advisor

Re: Interpreting Symbolic dump

if i start off EXA/INS i get output as below
> 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>