<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Access Violation in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/access-violation/m-p/3424115#M65634</link>
    <description>In addition to Hein's explanations and suggestions, you could also do s SET PROC/DUMP before running that failing image. This would create a process-dump (image-name.DMP in the current default directory) and you can then analyse that dump:&lt;BR /&gt;&lt;BR /&gt;$ ANAL/PROC/IMAGE=&lt;LOCATION-OF-IMAGE&gt; image-name.DMP&lt;BR /&gt;&lt;BR /&gt;this will get you into the debugger on the 'static' contents of the process virtual memory at the time of the ACCVIO.&lt;BR /&gt;&lt;BR /&gt;Start with:&lt;BR /&gt;DBG&amp;gt; EXA/INS @PC&lt;BR /&gt;&lt;BR /&gt;and then look around, where the 'bad value' or bad adress was coming from.&lt;BR /&gt;&lt;BR /&gt;Volker.&lt;/LOCATION-OF-IMAGE&gt;</description>
    <pubDate>Wed, 17 Nov 2004 13:14:38 GMT</pubDate>
    <dc:creator>Volker Halle</dc:creator>
    <dc:date>2004-11-17T13:14:38Z</dc:date>
    <item>
      <title>Access Violation</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/access-violation/m-p/3424113#M65632</link>
      <description>Hi All,&lt;BR /&gt;&lt;BR /&gt;Can anybody help on what the below error can &lt;BR /&gt;mean ?&lt;BR /&gt;Executing RMU for DEC Rdb V5.1-1                                                                      &lt;BR /&gt;%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=42441430, PC=00030A1C, PS=0000001B&lt;BR /&gt;%TRACE-F-TRACEBACK, symbolic stack dump follows                                                       &lt;BR /&gt; Image Name   Module Name     Routine Name    Line Number  rel PC      abs PC                         &lt;BR /&gt; DAS_D11      DAS_D11_3_PRO_B d11_3_pro_BEIS_        8062 0000017C    00030A1C                        &lt;BR /&gt; DAS_D11      DAS_D11_1_MAIN  main                   4701 00000194    00030194                        &lt;BR /&gt; DAS_D11      DAS_D11_1_MAIN  __main                    0 00000098    00030098                        &lt;BR /&gt;                                                        0 A273E170    A273E170                        &lt;BR /&gt;  DAS          job terminated at &lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Thanx</description>
      <pubDate>Wed, 17 Nov 2004 10:00:36 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/access-violation/m-p/3424113#M65632</guid>
      <dc:creator>Himanshu_3</dc:creator>
      <dc:date>2004-11-17T10:00:36Z</dc:date>
    </item>
    <item>
      <title>Re: Access Violation</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/access-violation/m-p/3424114#M65633</link>
      <description>&lt;BR /&gt;It meand that the program managed to move (ascii) data into a location where an address was expected:&lt;BR /&gt;&lt;BR /&gt;$ x="abcd"&lt;BR /&gt;$ x[0,32]=%x42441430&lt;BR /&gt;$ show symb x&lt;BR /&gt;  X = "0.DB"&lt;BR /&gt;&lt;BR /&gt;Maybe you recognize that short piece of string? The $x14 in the middle is 'control-t' or could be a byte count of 20 perhaps?&lt;BR /&gt;&lt;BR /&gt;With help of the program source for the reported line number you should be able to drill down.&lt;BR /&gt;&lt;BR /&gt;If you can reproduce, then maybe you can run with the debugger. First step would be a breakpoint on the offending line and look around. Next step might be a SET WATCH on the location holding the addres (stack variable or static variable?)?&lt;BR /&gt;An other debug technique might be to "SET BREA/EXCEP" to trap it when it breaks and use the debugger to brute-force look for the rest of the string.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Good luck!&lt;BR /&gt;Hein.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Wed, 17 Nov 2004 10:17:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/access-violation/m-p/3424114#M65633</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2004-11-17T10:17:42Z</dc:date>
    </item>
    <item>
      <title>Re: Access Violation</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/access-violation/m-p/3424115#M65634</link>
      <description>In addition to Hein's explanations and suggestions, you could also do s SET PROC/DUMP before running that failing image. This would create a process-dump (image-name.DMP in the current default directory) and you can then analyse that dump:&lt;BR /&gt;&lt;BR /&gt;$ ANAL/PROC/IMAGE=&lt;LOCATION-OF-IMAGE&gt; image-name.DMP&lt;BR /&gt;&lt;BR /&gt;this will get you into the debugger on the 'static' contents of the process virtual memory at the time of the ACCVIO.&lt;BR /&gt;&lt;BR /&gt;Start with:&lt;BR /&gt;DBG&amp;gt; EXA/INS @PC&lt;BR /&gt;&lt;BR /&gt;and then look around, where the 'bad value' or bad adress was coming from.&lt;BR /&gt;&lt;BR /&gt;Volker.&lt;/LOCATION-OF-IMAGE&gt;</description>
      <pubDate>Wed, 17 Nov 2004 13:14:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/access-violation/m-p/3424115#M65634</guid>
      <dc:creator>Volker Halle</dc:creator>
      <dc:date>2004-11-17T13:14:38Z</dc:date>
    </item>
  </channel>
</rss>

