D
dbeavon
Guest
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 ** ** 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.
Continue reading...
Continue reading...