PASOE ACCESS_VIOLATION on WIN32 ... reasonable or unreasonable? - Forum - OpenEdge Development - Progress Community

PASOE ACCESS_VIOLATION on WIN32 ... reasonable or unreasonable?

 Forum

PASOE ACCESS_VIOLATION on WIN32 ... reasonable or unreasonable?

This question is answered

We are running PASOE 11.7.4 on WIN32.  I've had several instances of access violation exceptions that cause the entire _mproapsv to crash and an "protrace" file is written to the ABL application working directory.

Below is an example of what the protrace may look like:

=====================================================
PROGRESS stack trace as of Mon Jan 14 13:00:00 2019
=====================================================

Progress OpenEdge Release 11.7 build 1685 SP04 on WINNT 

Startup parameters:
-pf C:\Progress\OpenEdge\startup.pf,-cpinternal ISO8859-1,-cpstream ISO8859-1,-cpcoll Basic,-cpcase Basic,-d mdy,-numsep 44,-numdec 46,(end .pf),-logginglevel 3,-logfile C:\OpenEdge\WRK\oepas1/logs/abl_dev_lumbertrack_dev.agent.log,-uburl AppServerDC://0.0.0.0:57439/,-logname abl_dev_lumbertrack_dev,-logentrytypes ASPlumbing,DB.Connects,4GLTrace,-ubpropfile C:\OpenEdge\WRK\oepas1\conf\openedge.properties,-ASID 2,-ipver IPv4,-sectok XXXXXXXXXXXXXXXXXXXXXX,-T C:\OpenEdge\WRK\oepas1/temp,-errorstack,-debugalert,-yx,-q,-Bt 2000,-tmpbsize 8,-db lumbertrack.db,-H ufpdev,-S 5011,-U ufp,-P ******,-ld lumbertrack

Exception code: C0000005 ACCESS_VIOLATION
Fault address:  00007FF7EA4DED71 01:000000000041DD71 C:\Progress\OpenEdge\bin\_mproapsv.exe

...



I am able to figure out the underlying problem in some cases.  For example, today a class was missing in the PROPATH directory (both the .cls file and the .r file were missing).  This took a lot longer to troubleshoot than it should have; this is because the "ACCESS_VIOLATION" prevents normal error messages from being written to the PASOE agent log.  Also, the openclient application receives a error message that is unhelpful (ie. a communication failure between the session-manager  and the MS-agent process) .   Another inconvenience is the fact that this type of error will cause the crash of the entire ms-agent process along with all the other sessions it may contain at the moment (but it seems like it should only impact a round-trip within a *single* ABL session).

Does it sound reasonable that missing code in the PROPATH should cause an ACCESS_VIOLATION?  Should it result in the crashing of the entire MS-AGENT?

Please let me know if this sounds reasonable.  I also tested what happens when a normal "p/r"  program is missing and that doesn't behave nearly as badly (it raises a STOP condition, and prints a message ** "MyCool.p" was not found. (293) )

Verified Answer
  • PASOE isn't supported on WIN32. Do you mean Windows? Please provide the PROTRACE to support so that we can take a look at it. No, the agent should not crash due to a missing .p.

  • To answer your question, it is never reasonable for the AVM, PASOE or otherwise, to crash.  It means there is a bug.  Missing a.cls or .r file is a pretty ordinary circumstance.  By that I don’t mean it is common.  I mean it is not a complicated scenario and I don’t know why that would cause a crash.  I would venture to say that this is a simplified description of the cause.  The protrace file you provided is not valid so it does not tell me anything. You are probably missing the .pdb files in your bin directory.

All Replies
  • Another thing is that this is one process / many threads.  If something bad happens and the process dies, then all goes away.  Same as another other program written using threads.
     
     
    Brian Maher
    Principal Engineer, Technical Support
    Progress
    Progress
    14 Oak Park | Bedford, MA 01730 | USA
    phone
    +1 781 280 3075
     
     
    Twitter
    Facebook
    LinkedIn
    Google+
     
     

  • Yes, I omitted the C and ABL traces to omit clutter.  My primary question is whether it is ever reasonable for the _mproapsv to crash to the OS when there is an error in the AVM.  It seems that an ABL developer should expect to troubleshoot ABL issues in the agent logs, rather than in native process dumps.  Even in the protrace there is nothing that indicates that the problem originated with a missing class file.

     

    Symbol Path:
     C:\Progress\OpenEdge\bin;C:\Progress\OpenEdge\pdbfiles
    
    
    Call Stack:
    Address           Frame
    00007FF7EA4DED71  00000033BDEFF250  pam_set_item+96C31
    00007FF7EA4DFA1F  00000033BDEFF300  pam_set_item+978DF
    00007FF7EA55B96A  00000033BDEFF3B0  pam_set_item+11382A
    00007FF7EA4CF9EA  00000033BDEFF3E0  pam_set_item+878AA
    00007FF7EA4A02D4  00000033BDEFF420  pam_set_item+58194
    00007FF7EA136C3E  00000033BDEFF5D0  updateImmutableProperty+35CE
    00007FF7EA136490  00000033BDEFF630  updateImmutableProperty+2E20
    00007FF7EA137820  00000033BDEFF660  updateImmutableProperty+41B0
    00007FF7EA1339EF  00000033BDEFF6A0  updateImmutableProperty+37F
    00007FF7EA13BBF5  00000033BDEFF6D0  updateImmutableProperty+8585
    00007FF7EA13CD22  00000033BDEFF890  updateImmutableProperty+96B2
    00007FF7EA13C5F5  00000033BDEFF930  updateImmutableProperty+8F85
    00007FF7EA15A123  00000033BDEFFC10  update_AS_srvrDeactivateProc+1423
    00007FF7EA14A621  00000033BDEFFCA0  updateImmutableProperty+16FB1
    00007FF7EA149C99  00000033BDEFFCE0  updateImmutableProperty+16629
    00007FF9050203BA  00000033BDEFFD10  o_exp+5A
    00007FF908077E94  00000033BDEFFD40  BaseThreadInitThunk+14
    00007FF9087FA251  00000033BDEFFDC0  RtlUserThreadStart+21
    
    
    ** ABL Stack Trace **
    
    --> UpdateBlackBoxRunHeaders app/Production/AppServer/BlackBox.p at line 2238  (\\grnetappm02\dbeavon\Wrk\OpenEdge\LumberTrack\app\Production\AppServer\BlackBox.r)
    
    ** Persistent procedures/Classes **
    
    Handle  File Name
    000000\\grnetappm02\dbeavon\Wrk\OpenEdge\LumberTrack\app\Production\AppServer\BlackBox.r
    001009\\grnetappm02\dbeavon\Wrk\OpenEdge\PasEntryPoint\Source\EntryProcedures\Server\StartupStateReset.r
    
    ** PROPATH **
    <several directories> 
    
    ** Databases (logical/type/physical) **
       lumbertrack         PROGRESS  lumbertrack
    
    ** End of Protrace **
    

     

    Hope this is clear.  Since I already know why I was encountering this ACCESS_VIOLATION, I don't need help in this particular scenario.  I was asking a more general/conceptual question.  Is it intentional that an ABL bug (eg. missing ABL code) causes the crash of the AVM runtime process and doesn't give any helpful error messages for troubleshooting?

    An ACCESS_VIOLATION is pretty far removed from the initial source of the problem (missing ABL code).  It isn't all that helpful to get an access violation and I'm guessing that it results from a combination of several types of errors, EG. a failure to properly handle failure.

  • PASOE isn't supported on WIN32. Do you mean Windows? Please provide the PROTRACE to support so that we can take a look at it. No, the agent should not crash due to a missing .p.

  • Sorry, I said WIN32 out of habit, ie.  (OPSYS = "WIN32").  That's what you get from speaking ABL all day instead of English.

    Thanks,  the next time I spend more than an hour to investigate an ACCESS_VIOLATION I will report it to tech support.  This one was just a matter of having a missing (cls/r) in the PROPATH of the PASOE agent...

  • To answer your question, it is never reasonable for the AVM, PASOE or otherwise, to crash.  It means there is a bug.  Missing a.cls or .r file is a pretty ordinary circumstance.  By that I don’t mean it is common.  I mean it is not a complicated scenario and I don’t know why that would cause a crash.  I would venture to say that this is a simplified description of the cause.  The protrace file you provided is not valid so it does not tell me anything. You are probably missing the .pdb files in your bin directory.

  • All I did was move some of the classes to another directory (moved both the cls files and related r-code files).  The only other thing that might make this unusual is that this portion of the PROPATH lives on a UNC (a NetApp share).  The testing was performed from a Windows version of PASOE -  OE v. 11.7.4.

    At the time I was actually trying to find various scenarios where -errorstack and -debugalert would provide some helpful messaging to the PASOE agent log file.  I have seen situations where those two parameters will provide a lot of helpful information when the AVM runs into trouble.  But, I've also seen situations where PASOE can encounter AVM errors at runtime, and the two parameters don't provide any additional information.  I believe that those parameters are only helpful for the types of errors that would otherwise show an "error alert box", (or whatever its equivalent is in the context of PASOE).

    Unfortunately - while I was testing -errorstack and -debugalert - I found this other type of error that makes the AVM extremely unhappy, and it stops showing any meaningful messages since the entire process encounters an ACCESS_VIOLATION (precluding the ability to write any more to the agent log).

  • > On Jan 14, 2019, at 1:56 PM, dbeavon wrote:

    >

    > Does it sound reasonable that missing code in the PROPATH should cause an ACCESS_VIOLATION?

    An access violation error (or error 49 on UNIX or Linux) means that code in the offending process has attempted to access a memory location outside of the process address space. This should never happen, especially if some file cannot be found.

    The only times (i can think of) they are NOT bugs are when:

    the executable or a dll has been corrupted on disk

    4GL code is calling a shared library or HLC function with incorrect arguments

    4GL code is calling a shared library or HLC function that has a bug in it.