|
HP OpenVMS Systemsask the wizard |
|
The Question is:
We have a process "msched" (written in C) that is using an oracle VMS client
(pre compiler) to generate Oracle SQL code to interface with the dB.
The process runs without incident for 15 days (approximately 400,000 reads),
then exits with the following error:
%DEBUGBOOT-W-EXQUOTA, process quota exceeded
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000000B
Improperly handled condition, image exit forced.
Signal arguments: Number = 0000000000000005
Name = 000000000000000C
0000000000000000
0000000000000000
FFFFFFFF808E5BE0
000000000000001B
Register dump:
R0 = FFFFFFFFFFFFFFFF R1 = 000000007B90C1F8 R2 = 00000000001D80E0
R3 = 0000000000000810 R4 = 0000000000000000 R5 = 0000000000000003
R6 = 000000000095E3C0 R7 = 00000000008FDDE8 R8 = 0000000000000000
R9 = 000000000095E3C0 R10 = 00000000008FDDE8 R11 = 0000000000000000
R12 = 0000000000969558 R13 = 00000000009694D0 R14 = 0000000000000000
R15 = 000000007B04A028 R16 = 0000000000AF806E R17 = 0000000000000810
R18 = 0000000000000000 R19 = 0000000000000001 R20 = 000000000000080C
R21 = 000000000035BEB0 R22 = 0000000000000001 R23 = 000000000035BE80
R24 = 000000000035BE88 R25 = 0000000000000003 R26 = 00000000006E35D0
R27 = FFFFFFFF82AC6BA0 R28 = 000000007BCCCA10 R29 = 000000007B049350
SP = 000000007B049350 PC = FFFFFFFF808E5BE0 PS = 100000000000001B
We believe the error is a pointer problem wihtin the Oracle generated code. Do
you have any suggestions how to prove this.
The Answer is : The OpenVMS Wizard would tend to recommend confirmation of the particular belief -- it is often easier to work forward and follow the steps involved in debugging -- topic (7552) and such -- and localize the problem first. Guesses are useful when correct, but guesses that cannot be verified or that prove inaccurate can serve to delay problem resolution. Please do realize that an application can run for years with a latent bug -- latent bugs can be timing issues, pool corruptions, quota leaks, or any number of other problems. Topic (1661) has an introduction to some of the more common application coding problems, and pointers to many of the related discussions. The immediate failure is an apparent access violation, though debugging this failure will require monitoring virtual address space usage (leaks), process quotas, and pool coherency -- the usual steps involved in debugging an application. Related topics include (2681) and (6099), as well as (1661) cited earlier. Also see (2624) and (2630). Also the ACCVIO topics: (837), (1705), (2195), (2223), (3215), (5533), (6065), (6495), (6776), (7551), etc. Also please see the ASTs, threads, reentrancy, and shared memory topics: (2681), (4647), (6099), and (6984). And debugging and traceback topics such as (4129) and (7552) will also be of interest. For virtual memory debugging and for typical steps in resolving memory heap corruptions -- for an introduction to fenceposts -- please see (3257). Please do apply the required mandatory ECO kits for OpenVMS and core layered products, as well as current versions and ECOs for relevent layered products, and please also confirm current versions and ECOs with the applicable third-party product vendors' support organizations.
|