<?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: Apache bad system call accvio in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507057#M5117</link>
    <description>That's all very well and interesting.  But I'm running HP's SWS and HP's build of PHP.  It's open-source PHP code that's showcasing this problem, so the question then becomes "should the latest verson of PHP running on a supported version of SWS generate ACCVIOs?"&lt;BR /&gt;&lt;BR /&gt;HP's the company that linked this stuff, not me.  I've met all the pre-reqs for this kit (OpenVMS 7.3-2, TCP/IP 5.4-4, and Apache/SWS v1.3-latest).  My question is why isn't YOUR software working?  I know nothing about the internals of PHP or Apache, but would be more than happy to get a process dump for HP to look at.&lt;BR /&gt;&lt;BR /&gt;I am trying to be civil (exceedingly difficult after contractors took down our entire computer room last night, corrupting my Oracle installation, but that's not your problem), but asking me to run debug on HP's code doesn't exactly sound like "support" to me.  And according to my latest DSNlink termination letter, ITRC ("HP's premier support site for IT professionals") is supposed to be my recourse now.&lt;BR /&gt;&lt;BR /&gt;So, how would you like your process dump served?</description>
    <pubDate>Fri, 18 Mar 2005 11:05:23 GMT</pubDate>
    <dc:creator>Aaron Sakovich</dc:creator>
    <dc:date>2005-03-18T11:05:23Z</dc:date>
    <item>
      <title>Apache bad system call accvio</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507053#M5113</link>
      <description>I'm running CSWS v1.3-1 update v1 with PHP v1.2-1.  On PHP code that works just fine on another system (albeit running SWS v2), I sometimes get PHP blowing off the server process associated with the specific client connection.&lt;BR /&gt;&lt;BR /&gt;In error_log., I see:&lt;BR /&gt;&lt;BR /&gt;[Thu Mar 17 11:15:55 2005] [notice] child pid 490 exit signal Bad system call (12, 0x1000000C)&lt;BR /&gt;&lt;BR /&gt;And in the Apache$$000.log file, I see:&lt;BR /&gt;&lt;BR /&gt;$! PHP_SETUP.COM&lt;BR /&gt;$!  &lt;BR /&gt;$ VERIFY = F$VERIFY (0)&lt;BR /&gt;$ EXIT 1&lt;BR /&gt;$ SET NOVERIFY ! Required by CGI (else malformed header error)&lt;BR /&gt;%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000&lt;BR /&gt;&lt;BR /&gt;  Improperly handled condition, image exit forced.&lt;BR /&gt;    Signal arguments:   Number = 0000000000000005            &lt;BR /&gt;                        Name   = 000000000000000C                 &lt;BR /&gt;                                 0000000000010000                               &lt;BR /&gt;                                 0000000000000000&lt;BR /&gt;                                 0000000000000000&lt;BR /&gt;                                 000000000000001B &lt;BR /&gt;  &lt;BR /&gt;    Register dump:                 &lt;BR /&gt;    R0  = 000000000000001C  R1  = 000000000000001D  R2  = 0000000000000000&lt;BR /&gt;    R3  = 0000000000000000  R4  = 0000000000000000  R5  = 0000000000000000&lt;BR /&gt;    R6  = 0000000000000000  R7  = 0000000000000000  R8  = 0000000000000009&lt;BR /&gt;    R9  = 00000000010F59B0  R10 = 0000000000000006  R11 = 0000000001328000&lt;BR /&gt;    R12 = 0000000000000000  R13 = 00000000006368F8  R14 = 0000000000636CBC&lt;BR /&gt;    R15 = 0000000000636CB8  R16 = 000000007AE67BF8  R17 = 0000000000000000&lt;BR /&gt;    R18 = 0000000000000003  R19 = 0000000000000001  R20 = 000000007FFF0000&lt;BR /&gt;    R21 = 0000000000000002  R22 = 0000000000000000  R23 = 0000000000000000&lt;BR /&gt;    R24 = 0000000037DF97EA  R25 = FFFFFFFF817F4A00  R26 = 0000000000000000&lt;BR /&gt;    R27 = 0000000000000004  R28 = 0000000000000000  R29 = 0000000000000000&lt;BR /&gt;    SP  = 000000007AE67C30  PC  = 0000000000000000  PS  = 300000000000001B&lt;BR /&gt;  APACHE$WWW   job terminated at 17-MAR-2005 11:15:55.27 &lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;I'm at a loss as to what's going on -- I just know that if I continue to attempt to load the requested page, it will eventually go through without the accvio!&lt;BR /&gt;&lt;BR /&gt;I seem to recall seeing something like this before, but for an older version of VMS -- I'm running 7.3-2.  &lt;BR /&gt;&lt;BR /&gt;Any ideas what might be going bad?&lt;BR /&gt;&lt;BR /&gt;TIA,&lt;BR /&gt;Aaron</description>
      <pubDate>Thu, 17 Mar 2005 12:38:19 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507053#M5113</guid>
      <dc:creator>Aaron Sakovich</dc:creator>
      <dc:date>2005-03-17T12:38:19Z</dc:date>
    </item>
    <item>
      <title>Re: Apache bad system call accvio</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507054#M5114</link>
      <description>Aaron,&lt;BR /&gt;&lt;BR /&gt;Virtual Address 00000000&lt;BR /&gt;&lt;BR /&gt;that means a serious (fatal) addressing error!&lt;BR /&gt;&lt;BR /&gt;NO address below 512  (%X200) is ever valid, and that is a pretty nice safeguard for early detection of straightforward programming errors, it it also often traps situations where data manipulation somehow gets de-railed.&lt;BR /&gt;&lt;BR /&gt;PS.&lt;BR /&gt;from your profile:&lt;BR /&gt;"I have assigned points to   27  of   45  responses to my questions.  "&lt;BR /&gt;&lt;BR /&gt;Please try to find some time for catching-up. Those responding also found time for you!&lt;BR /&gt;The easy way to find them is via the link to your ID, and then "topics with unassigned answers"&lt;BR /&gt;&lt;BR /&gt;Proost.&lt;BR /&gt;&lt;BR /&gt;Have one on me.&lt;BR /&gt;&lt;BR /&gt;Jan</description>
      <pubDate>Thu, 17 Mar 2005 13:35:56 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507054#M5114</guid>
      <dc:creator>Jan van den Ende</dc:creator>
      <dc:date>2005-03-17T13:35:56Z</dc:date>
    </item>
    <item>
      <title>Re: Apache bad system call accvio</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507055#M5115</link>
      <description>The majority of those unassigned points were due to one old thread where a bunch of folks posted "me too".&lt;BR /&gt;&lt;BR /&gt;Now, I've done my part by assigning 0 to all those "me too"s, does anyone have a solution for me?</description>
      <pubDate>Thu, 17 Mar 2005 14:42:25 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507055#M5115</guid>
      <dc:creator>Aaron Sakovich</dc:creator>
      <dc:date>2005-03-17T14:42:25Z</dc:date>
    </item>
    <item>
      <title>Re: Apache bad system call accvio</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507056#M5116</link>
      <description>Aaron,&lt;BR /&gt;&lt;BR /&gt;  This is a fairly generic error message. The ACCVIO gives you Virtual Address and PC. What's interesting here is they're both 0. Typically that means a branch to a zero address.&lt;BR /&gt;&lt;BR /&gt;  One common reason for this would be a link time failure to resolve a reference. At run time you try to call a non-existent routine -&amp;gt; ACCVIO.&lt;BR /&gt;&lt;BR /&gt;  Another possibility is a call frame being corrupted, overwriting the return address to zero. So, then the routine attempts to RET, you get a 0/0 ACCVIO. This could be a symptom of a (failed) attempt at a buffer overrun exploit.&lt;BR /&gt;&lt;BR /&gt;  Another possibility from your description... you're running different versions, so maybe it's a bug fixed in the other version? (stating the obvious?)&lt;BR /&gt;&lt;BR /&gt;  If you can identify the process getting the error, try enabling process dumps, and do a post mortem to try and work out what it thought it was doing at the time.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Thu, 17 Mar 2005 20:11:56 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507056#M5116</guid>
      <dc:creator>John Gillings</dc:creator>
      <dc:date>2005-03-17T20:11:56Z</dc:date>
    </item>
    <item>
      <title>Re: Apache bad system call accvio</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507057#M5117</link>
      <description>That's all very well and interesting.  But I'm running HP's SWS and HP's build of PHP.  It's open-source PHP code that's showcasing this problem, so the question then becomes "should the latest verson of PHP running on a supported version of SWS generate ACCVIOs?"&lt;BR /&gt;&lt;BR /&gt;HP's the company that linked this stuff, not me.  I've met all the pre-reqs for this kit (OpenVMS 7.3-2, TCP/IP 5.4-4, and Apache/SWS v1.3-latest).  My question is why isn't YOUR software working?  I know nothing about the internals of PHP or Apache, but would be more than happy to get a process dump for HP to look at.&lt;BR /&gt;&lt;BR /&gt;I am trying to be civil (exceedingly difficult after contractors took down our entire computer room last night, corrupting my Oracle installation, but that's not your problem), but asking me to run debug on HP's code doesn't exactly sound like "support" to me.  And according to my latest DSNlink termination letter, ITRC ("HP's premier support site for IT professionals") is supposed to be my recourse now.&lt;BR /&gt;&lt;BR /&gt;So, how would you like your process dump served?</description>
      <pubDate>Fri, 18 Mar 2005 11:05:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507057#M5117</guid>
      <dc:creator>Aaron Sakovich</dc:creator>
      <dc:date>2005-03-18T11:05:23Z</dc:date>
    </item>
    <item>
      <title>Re: Apache bad system call accvio</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507058#M5118</link>
      <description>Aaron, log a call with your CSC. SWS is supported on systems with a VMS support contract. A call can be logged using the web interface elsewhere on itrc or by telephone.&lt;BR /&gt;</description>
      <pubDate>Fri, 18 Mar 2005 12:30:04 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507058#M5118</guid>
      <dc:creator>Ian Miller.</dc:creator>
      <dc:date>2005-03-18T12:30:04Z</dc:date>
    </item>
    <item>
      <title>Re: Apache bad system call accvio</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507059#M5119</link>
      <description>for cross-reference:&lt;BR /&gt;&lt;BR /&gt;Same kind of ACCVIO described in thread:&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1009572" target="_blank"&gt;http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1009572&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;Problem seems to be related to 0-length files accessed by PHP&lt;BR /&gt;&lt;BR /&gt;Volker.</description>
      <pubDate>Mon, 13 Mar 2006 02:10:37 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/apache-bad-system-call-accvio/m-p/3507059#M5119</guid>
      <dc:creator>Volker Halle</dc:creator>
      <dc:date>2006-03-13T02:10:37Z</dc:date>
    </item>
  </channel>
</rss>

