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) )
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.
|
|
||||
|
Brian Maher
|
||||
|
Principal Engineer, Technical Support
|
||||
 |
||||
|
Progress
|
||||
|
14 Oak Park | Bedford, MA 01730 | USA
|
||||
|
||||
|
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.
