Note: If you encounter business function error while using standard application or UBE, it maybe already reported, install ESU for fix. If issue has not been reported, open service request with team that support the application or UBE, example, select product JD Edwards EnterpriseOne Sales Order Management while opening a SR if encountering business function issue while using P4210. If you encounter issue with standard business function used in custom object (application or UBE), check if issue also appear with standard application or UBE. If issue does not appear, most likely there is no bug with the standard business function.
This document is the second part of document 1464687Case Study on Memory Violation, Memory Corruption, Memory Overwrite, Access Violation and Zombie Kernel Caused by Standard Business Functions for further detail on Memory Corruption. and this document is to cover case studies which you face from both Interactive Application and Batch Application.
This document is intended to help internal JDE developer on what to check when hitting memory errors in EnterpriseOne and how to apply possible fix for these errors while working on reported bug. But information in this document maybe helpful for developing custom business function.
This document does not cover any Memory Corruption issues caused by the Tools Foundation Layer which is usually fixed through tools release upgrade. This document mainly focuses on memory errors caused by standard business functions which results in CallObject Kernels to crash or runbatch application to fail.
Caution: This document may contain information, software, products or services which are not supported by Oracle Support Services and are being provided ‘as is’ without warranty. Please refer to the following site for My Oracle Support Terms of Use: https://support.oracle.com/CSP/ui/TermsOfUse.html. For custom business function, field services may need to be engaged.
Refer to document 1464687Case Study on Memory Violation, Memory Corruption, Memory Overwrite, Access Violation and Zombie Kernel Caused by Standard Business Functions for further detail on Memory Corruption.
Case Study:
Case 1 - Memory overwrite
For this example, two business functions are not able to communicate properly. The size of string (Character Array) of calling routine is smaller than the size assigned by called routine.
JDE.log:
INFO: Entering kernel signal handler, process exiting soon: iParam: 1338273596 INFO: In kernel signal handler, starting alarm handler: iParam: 1338273597 INFO: Done setting IPC Handle State structures to abandoned, process exiting immediately: iParam: 1338273597
JDEDEBUG.log:
Calling Business function F4211FSEditLine from Level 1 for UserID. Application Name [P4210], Version [ZJDE0001] (BSFNLevel = 1)
Calling Business function ProcessOrderLine from F4211FSEditLine for UserID. Application Name [P4210], Version [ZJDE0001] (BSFNLevel = 2) Calling Business function DetermineTransportationInterface from ProcessOrderLine for UserID. Application Name [P4210], Version [ZJDE0001] (BSFNLevel = 3) IN->[ 1] cSuppressErrorMessage [] IN->[ 2] szErrorMessageID [] IN->[ 3] szOrderType [SO] IN->[ 4] szLineType [S ] IN->[ 5] cSys49Interface [] IN->[ 6] cSys49TInterface [] IN->[ 7] szInitalShipSts []
Calling Business function GetEnvironmentValue from DetermineTransportationInterface for UserID. Application Name [P4210], Version [ZJDE0001] (BSFNLevel = 4) Return value is 2 for GetEnvironmentValue. (BSFNLevel = 4) Calling Business function GetUDC from DetermineTransportationInterface for UserID. Application Name [P4210], Version [ZJDE0001] (BSFNLevel = 4) IN->[ 1] szDataDictionaryItem [] IN->[ 2] szSystemCode [49] IN->[ 3] szRecordTypeCode [SD] IN->[ 4] szUserDefinedCode [SOS ] IN->[ 5] mnKeyFieldLength [4] ... Entering JDB_FetchKeyed SELECT * FROM PRODCTL.F0004 WHERE ( DTSY = '49' AND DTRT = 'SD' ) Entering JDB_FetchKeyed SELECT * FROM PRODCTL.F0005 WHERE ( DRSY = '49' AND DRRT = 'SD' AND DRKY = ' SOS' ) Fetched the record OUT->[ 1] szDataDictionaryItem [] OUT->[ 2] szSystemCode [49] OUT->[ 3] szRecordTypeCode [SD] OUT->[ 4] szUserDefinedCode [SOS] OUT->[ 5] mnKeyFieldLength [4] ... Return value is 0 for GetUDC. (BSFNLevel = 4) Exiting jdeGetCallStack (succeeded): PID=20371
Code example and fix: Based on B4902540 - DetermineTransportationInterface): The size of string (character array) in calling routine is smaller than called routine
*** Break In Code of B4902540 *** void I4202540_DetermineTransportationInterface (LPDSD4902540 lpDS, LPDSD4902540INTERNAL lpdsInternal) { /* JCHAR szOrdLnType[4] = {0}; SAR 8822535 - change variable to 10 characters plus null */ JCHAR szOrdLnType[11] = {0}; /* SAR 8822535 - variable now same length as UserDefinedCode */
Note: This type of issue is platform specific. In C, string is a character array with termination (NULL Character '\0') so it is important to define valid size of array.
Case 2 - Buffer Overflow (called Business Function fails into zombie)
Called business function fails to return to calling routine. This type of memory error can occur when a certain routine is checking individual characters in a character array (namely, string).
JDE.log:
Last Debug Time Stamp: Thu May 3 17:06:10.843219 INFO: Entering kernel signal handler, process exiting soon: iParam: 1336057570 Last Debug Time Stamp: Thu May 3 17:06:11.846414 INFO: In kernel signal handler, starting alarm handler: iParam: 1336057571 Last Debug Time Stamp: Thu May 3 17:06:11.846414 INFO: Done setting IPC Handle State structures to abandoned, process exiting immediately: iParam: 1336057571
JDEDEBUG.log:
Calling Business function RemoveLeadingBlanksFromUDC from Level 1 for JDE. Application Name [R09E115], Version [XJDE0001] (BSFNLevel = 1) IN->[ 1] szSystemCode [09E] IN->[ 2] szUserDefinedCodes [EL] IN->[ 3] cError [] SELECT * FROM TESTCTL.F0005 WHERE ( DRSY = '09E' AND DRRT = 'EL' ) ORDER BY DRSY ASC,DRRT ASC,DRKY ASC Fetched the record
Calling Business function RemoveLeadingBlanks from RemoveLeadingBlanksFromUDC for JDE. Application Name [R09E115], Version [XJDE0001] (BSFNLevel = 2) IN->[ 1] szString [ALHA ] Entering jdeCloseDictionary Exited jdeCloseDictionary with DDType 0 Entering jdeGetCallStack: PID=24459 Exiting jdeGetCallStack (succeeded): PID=24459
Code example and fix: B0200019 - RemoveLeadingBlanks (Leading Blanks Scrub). The loop exceeds the size allocated (buffer overflow). Similar issue can be found at B980001 - StripTrailingBlanksOnDataSource (Strip Trailing Blanks On Data Source) and B0100068 - AddressBookWordSearchBuild (Address Book Word Search Build).
Note: Certain compiler may give you warning message C6201 for this type of coding as below,
C6201: Index <variable> is out of valid index range <start> to <end> for possibly stack allocated buffer <buff> Example: Index 41 is out of valid index range 0 to 40 for possibly stack allocated buffer szWordField JCHAR szWordField[41]; for (n = 0; w <= 41; w++) { : : } Solution: Correct the code so that it does not go past the end of the array bounds. for (n = 0; w < 41; w++) --- or --- for (n = 0; w <= 40; w++)
Case 3 - Integer value is too long
This case is to show possible memory corruption which is caused by data. Similar issue can occur when a certain string value contains Special Character in it. For special characters in C language, refer to <Document 1271740.1> E1: BSFN: How to Write a C Business Function to Return a Special Character.
e1root_*.log:
View Job Status (P986110B|W986110BA) row exit Print from HTML client causes zombie for jobs executed on second Enterprise Server. The user also receives this error:
There was a problem with the sever while running the business function GetPrinterInfoFromF986110. Please exit the application and restart it. Button clicked Line number 2 P986110B_W986110BA
JDE_*.log:
3532/5112 MAIN_THREAD Wed Feb 22 17:14:13.535004 IPCMISC.C299 Call stack for process 6636, thread 720: CTOOL.dll/B986162A/GetPrinterInfoFromF986110
JDEDEBUG_*.log:
Calling Business function GetPrinterInfoFromF986110 from Level 1 for JDE. Application Name [P986110B], Version [ZJDE0001] (BSFNLevel = 1) IN->[ 1] szPrinterName [] IN->[ 2] szUserID [] IN->[ 3] szExecutionHostName [LogicServerMachineName] IN->[ 4] szEnvironmentName [PD910] IN->[ 5] mnServerJobNumber [123456789] ...
Code Example and Fix: Based on B986162A - GetPrinterInfoFromF986110 (Get Printer Info From F986110) : No fix is available because issue is caused by faulty input value. Same issue can be found in calling B9861102 - PrintF986110 (Print F986110) which gets called 'View PDF, View CSV, View OSA)
*** Break In Code of B986162A *** JDEBFRTN (ID) JDEBFWINAPI GetPrinterInfoFromF986110 (LPBHVRCOM lpBhvrCom, LPVOID lpVoid, LPDSD986162A lpDS) { MathNumericToInt( &lpDS->mnServerJobNumber, &jobNbr ); *** Break In Code ***
Note:
The nature of F986111.JCJOBNBR is F0002.N004 so any value in this column has to be shorter than 8 numeric value.
The first problem is that the column value is updated wrongly (longer than 8) and this is root cause of issue. In other words, through standard application there is no way to populate the value which is bigger than 8 digit. On a side note ,this appears to be more related with the history of EnterpriseOne. The DD Alias ( DOCO, DCO, ITM, AID and so on ) which are consumers of Next Numbers were written based on 8 digit numeric values. So this may be reason why we have 8 digits definition in F0002/F00021 and so on.
The address (location in memory) of any variable is obtained by placing the operator ``&'' before its name. Therefore &jobNbr is the (memory) address of jobNbr. The content of the memory location referenced by a pointer is obtained using the ``*'' operator (this is called dereferencing the pointer). Thus, *px refers to the value of x (when px is pointer to x)..
Case 4 - R42565 (Print Invoice) Falls into Zombie
R42565 (Print Invoice) falls into zombie in server when the processing options are set to send an email. The UBE fails to run on server but it is running alright when submitted locally.
JDEDEBUG_*.log
End dumping data structure for business function EmailHeadingCache Entering jdeCacheInit - Name:[12297697B4202370] Created new cache - hCache:[0766ACF0] hCache:[0766ACF0] Nm:[012297697B4202370] Recs:0 Curs:0 Hnds:1 Cchs:3 INIT new jdeCacheAdd
For this case study, issue is coming from size of szCacheName with value 16 so during runtime 32 byte memory is to be assigned to hold cache name.
szCacheName[16] has to be divided into 3 components
JobNumber
Function Name: B4200370 (8 character)
Termination Character (or, Null Charcter '\0') (1 character)
: So if mnJobnumberA_JOBS is greater than 7digit numeric value, the variable szCacheName is not able to hold it.
Resolution:
This issue is reported in <Bug:13913268> "R42565 FAILS WHEN EMAIL TURNED ON FOR JOB NUMBER WITH EIGHT POSITIONS". You can apply the ESU for this Bug. The size of szCacheName is now increased from 16 to 50.
Note: Similar issue is reported through <Bug 11008628> : SALES UPDATE ENDS IN ERROR - SAR: 8926589 in running R42800 (Sales Update) which is caused by short cache name definition or mismatch in cache name size
Case 5 - ACCESS VIOLATION
This error is coming usually in
function cleanup where free memory, close handles and so on
Copy/Compare memory which is NULL pointer
is used on 64-bit Windows Servers.
Example 1: P45550 (F4072 Global Update Engine) ends in error and JDE_*.log contains ACCESS VIOLATION
Code sample in B4500500.c *** Break In Code ***
ID IB4500500_FunctionCleanUp (...) { : if ( hRequest1 != (HREQUEST)NULL ) { JDB_CloseTable(hRequest1); /* Check whether HREQUEST is NULL or not before calling JDB_CloseTable() */ } : if ( lpList ) /* Check lpList and only this test is success then call jdeFree() to free memory */ { if ( lpList[0] ) { if ( lpList[0][0] ) { jdeFree ( (void *) lpList[0][0] ) ; } jdeFree ( (void *) lpList[0] ) ; } jdeFree ( (void *) lpList ) ; } : *** Break In Code ***
Resolution: Check NULL before accessing array to free memory
Code sample in XT4111Z1.c
*** Break In Code *** BOOL IXT4111Z1_GetLotDefault () { : if (lpdsF4102) /* Check lpdsF4102 (data pointer to F4102) is NULL or not before use it*/ { dsLotDefault.idF4102ItemBranchPtr = (ID)jdeStoreDataPtr(hUser, lpdsF4102); } else { dsLotDefault.idF4102ItemBranchPtr = (ID)0; } *** Break In Code ***
Resolution: Store Data Pointer only when IF TEST is SUCCESS
Refer Function Cleanup section for more API which may cause this error. Again it is important to check JDE_*.log and dump file and/or callstacks in hitting error
Example 2: P4210 (Sales Order) falls into zombie in updating Sales Order Header information with JDE_*.log contains ACCESS VIOLATION
Memory dump:-
====> Exception C0000005 ACCESS_VIOLATION occurred in thread 1992 with call stack: _jdeStrncpy@12! jdeunicode.dll _I4200310_WriteHdrRecord@28! CSALES.dll _F4211FSEndDoc@12! CSALES.dll _jdeCallObjectV2@44! jdekrnl.dll
if (IsStringBlank(lpdsF42UI01->zhrorn)) { jdeStrncpy((JCHAR *)(lpdsF42UI01->zhrorn), (const JCHAR *)(lpds4200310D->lpdsF42UI11->zdrorn), DIM(lpdsF42UI01->zhrorn)-1); }
[with Bug 17695315]
if (IsStringBlank(lpdsF42UI01->zhrorn) && (lpds4200310D->lpdsF42UI11 !=(LPF42UI11)NULL)) /* ORCL - before reference cache, check whether it is NULL or not */ { jdeStrncpy((JCHAR *)(lpdsF42UI01->zhrorn), (const JCHAR *)(lpds4200310D->lpdsF42UI11->zdrorn), DIM(lpdsF42UI01->zhrorn)-1); }
*** Break In Code ***
}
To fix this issue, apply ESU which contains <Bug 17695315> : P42101 TRANSACTION ERROR WITH KIT ITEM WHEN CHANGING CARRIER
Case 6 - Memory Overwrite II
This type of error can come in API jdeStrcpy() and jdeStrncpy() when the size between left operand is different from right operand. Example 1: In AS400, all the inventory transaction fails when transaction UOM is different from Primary UOM
Resolution: sizeof on AS400 returns a large value that causes a memory overwrite. Just copy the nonblank values over, the sizes were coded to match correctly.
Note:
Frequently, the mis-use of sizeof() and DIM() operator may cause buffer overwrite problem. Note that DIM(A) = sizeof(A)/sizeof(A[0]).
<Document 626598.1> E1: BSFN: Unicode and C Business Functions
Code Sample in B4900211
*** Break In Code *** JDEBFRTN (ID) JDEBFWINAPI ShipmentSequencingSalesOrderEdit (LPBHVRCOM lpBhvrCom, LPVOID lpVoid, LPDSD4900211A lpDS) { /************************************************************************ * Variable declarations ************************************************************************/ JCHAR szOrderLineType[11]; /* before correction: JCHAR szOrderLineType[3]; */ /************************************************************************ * Declare structures ************************************************************************/ DSD0005 dsD0005; /*Get UDC*/ : /************************************************************************ * Main Processing ************************************************************************/ /* Build the Order Type/Line Type concatenation */ jdeStrcpy((JCHAR *)(szOrderLineType),(const JCHAR *)lpDS->szOrderType); jdeStrcat(szOrderLineType, lpDS->szLineType);
Resolution: Synchronize the size of string in calling GetUDC
Case 7 - Column Array Mismatch
The Columns array used to open the table did not match the data structure used to fetch the data from the table; as a result the fetched record from table got incorrectly mapped to the cache Data Structure in return this resulted in memory overwrite. Most of standard business function stores data pointer rather than returning actual column value but when there is any business function which has to return column value to data structure defined, the sequence of columns for a specific table (through Array) has to be in synch with data structure defined.
Example: P3210 (Configured Item Revisions) issues WEB CLIENT EXCEPTION and CallObject Kernel ends abruptly (output LPDS does not shows all) or value returns are not valid.
To fix this issue: Either change Column Array or change the sequence of data structure. For this issue refer <Bug 14663809> - 9.1 WRONG COLUMN ARRAY IN B3202030 CAUSE ZOMBIE KERNEL
Note: JDE.log may contains below error for this issue (but the cause of above error message is caused by column array mismatch between Column Array and Data Structure),
====> Exception C0000005 ACCESS_VIOLATION occurred in thread 3824 with call stack: _jdeStrcpy@8! jdeunicode.dll _I3201650_RetrieveCostMethod@16! CMFG.dll _RollupPriceCostWeightVolume@12! CMFG.dll
Memory violation in Batch Application:
Memory Violation message in PDF or JDEDEBUG.log shall not reflect actual offending business function. Because Memory Violation message in PDF is to be written by UBE Kernel, which reads and process line by line based on event rule as a result it only indicates the first level business function (which is called by report). So if a certain UBE is calling any business function through UBE Kernel, which is waiting for called business function to return. If it fails, then Memory Violation Message is to be written in PDF. For this reason if you turn on UBE log, same message can be retrieved. For this case, it is very important for you to capture both UBE kernel log and CallObject Kernel log by setting tracing (which records callobject process) and UBE Logging Level 6.
As we have describe above, Memory Violation can be understood as violating memory safety which in turn returns unexpected result. So you need to resolve this message to guarantee the result you are getting is correct and valid.
Unlike interactive application, transaction volume in a certain batch may affect result so verify that whether there is any memory leak. If so, resolve memory leak first to move on to memory corruption. Most of time, memory leak and memory corruption can be related in batch.
Example 1:
R47011 (EDI Sales Order) Ends in Memory Error
A. PDF:
EventRule : Business Function R47011DetailDoSectionProcess at line 36 for Event 13 in Section Read/Edit EDI Detail has caused a memory violation.
B. How to debug:
1. Turn on logging for both UBE kernel and CallObject Kernel and focus on the business function ends abruptly and business function called by this termination. 2. Look for bug based on the business function object ID retrieved by above 3. (Optionally) review the business function code and make it sure codes for fix exist in it
Example 2:
R3483 (MRP) ends in Memory Violation
A. UBE Log
--UBE--[0]-- EventRule : Business Function MRPWriteDateBuckets at line 295 for Event 13 in Section Read Item Branch Records has caused a memory violation. --UBE--[2]-- Finished with UBE Message Loop --UBE--[1]-- Total Pages processed are 1 --UBE--[6]-- Printing Object Value = 'ERROR:' --UBE--[6]-- Printing Object Value = 'EventRule : Business Function MRPWriteDateBuckets at line 295 for Event 13 in Section Read Item Branch Records has caused a memory violation.' --UBE--[1]-- Before PRT_EndDoc --UBE--[6]-- Unsuccessfully Finishing Engine. Review UBE log for errors.
B. Cause: R3483 heavily uses array and/or array of array heavily because data has to be handled dynamically. Most commonly memory error is coming when allocated memory is smaller than actual cache to be created based on transaction data.
C. How to fix it:
nNumberOfDays + nNumberOfWeeks + nNumberOfMonths + nNoOfPastDuePeriods has to be smaller than MAX_CAPACITY_DATES 56 (defined in B3400360.c)
nInitialBranchCount has to be bigger than actual branches for planning
For this example, there are more than 400 branches to deal with whereas user did not specify initialbranchcount so default value 100 was used allocating memory. So when 101th branch tries to create date cache (copy based on date branch) it hits memory error. To fix this type of error, make it sure the initialization value is big enough to hold actual data.
Example 3:
R42800 (Sales Update) ends memory error
A. PDF reads:
ERROR: EventRule : Business Function AcctRecFSEndDoc at line 674 for Event 13 in Section Sales Update And Report has caused a memory violation.
B. jde_*.log
====> Exception C0000005 ACCESS_VIOLATION occurred in thread 37000 call stack dumped in file <E:\JDEdwards\E900\DDP\log\jde_43532_1333518572_1_dmp.log>: iParam: 0000000000 INFO: Entering kernel signal handler, process exiting soon: iParam: 1333518575 INFO: Done setting IPC Handle State structures to abandoned, process exiting immediately: iParam: 1333518575 BSFN C0000005 ACCESS_VIOLATION E:\JDEdwards\E900\DDP\log\jde_43532_1333518572_1_dmp.log
JDB4200003 - OPEN TABLE NOT CLOSED = F42119, opened from File=b4200260.c, Function=WriteSalesHistoryOrLedger, Line=185. JDB9900600 - Failed to store value, maximum exceeded. Probable cause is forgetting to call jdeRemoveDataPtr()
CAC0001034 - (jdeCacheTerminate) NULL cache handle encountered: jdeCacheTerminate failed JDB9900600 - Failed to store value, maximum exceeded. Probable cause is forgetting to call jdeRemoveDataPtr() JDB9900600 - Failed to store value, maximum exceeded. Probable cause is forgetting to call jdeRemoveDataPtr()
31268/43020 MAIN_THREAD Wed Apr 04 14:49:47.132000 ipcmisc.c299 Call stack for process 43532: CDIST.dll/UNKNOWN/SaveARDetailCacheTerminate CALLBSFN.dll/B0000183/jdeFreeEnvBSFN
E. How to Fix
For this example, error "JDB9900600 - Failed to store value, maximum exceeded. Probable cause is forgetting to call jdeRemoveDataPtr()" is harmful. Since data pointer can't be referenced after hitting this error, the result you are getting may not be valid. Identify which routine is leacking data pointer and resolve it.
For this example, actual implemenation is written in event rule (either do not call routine to fetch/store data pointer or kill it after using it).
Example 4:
R893201H ends in error:
A. jde_*_dmp.log
****************************************** Mon Jun 25 16:21:54 2012 ****************************************** Generating call stacks for PID 7232 ****************************************** ====> Exception C0000005 ACCESS_VIOLATION occurred in thread 2832 with call stack: 0x7c82c912.<nosymbols>! ntdll.dll 0x7c8338a2.<nosymbols>! ntdll.dll 0x7c82b46b.<nosymbols>! ntdll.dll calloc! MSVCR71.dll
B. How to fix it?
This can be unique and extrem example because the behavior of R893201H (which is meant for table conversion for Configurator from B7 to 8.9 and above). Firstly this uses huge amount of resources (depends on volume of data) so this type of error may be written through Windows Heap Memory Manager. As a result, logs created from JDE kernels may not contain any detail information on cause of error. For this example, this type of error can be overcome by running this conversion UBE in deployment server.
Example 5:
R01800P (Address Book Purge) ends in error when 8 digit Address Book Number is selected:
This is unique example of memory overriwrite in submitting R01800P to 64 bits windows platform. For this example, Job Status is updated to 'E-Error' but both JDE.log and JDEDEBUG.log may not leave any error in it. The reason is that the 1st level BSFN (which is directly called by R01800P faces Memory Overwrite.
So it is important to capture full set of CallObject Kernel log and analyze it along with the source code called (for this example, B0100017 - ChecktheABDelete (F0101 Edit Address Book Delete). Note that same function gets called in your clicking Delete button in P01012 WEB CLIENT EXCEPTION error shall be appeared in HTML client.
A. B0100017.c
*** Break In Code *** JDEBFRTN(ID) JDEBFWINAPI ChecktheABDelete (LPBHVRCOM lpBhvrCom, LPVOID lpVoid, LPDSD0100017 lpDS) { *** Break in Code *** JCHAR Hold[8] ={_J('\0')}; /* Note that 16 bytes of memory is allocated */ *** Break in Code *** FormatMathNumeric (Hold, &lpDS->mnAddressNumber); /* When mnAddressNumber is 8 digit it requires 18 bytes of memory */ *** Break In Code ***
B. How to fix it?
Apply ESU which includes <Bug 11037315>: UNNECESSARY CHECK IN DELETING - SAR: 8956833 Through above fix memory will be allocated 18 bytes as below, JCHAR Hold[9] ={_J('\0')}; : For this example, String Variable which is Character Array [9] implements NULL/Termination Character which indicated ends of string.
Example 6:
R47131 (EDI Inbound Purchase Order Change) ends in memory violation error when Blank UDC values are deleted.
First of all, refer to <Document 1115344.1> E1: 42: Open Cursor for Cache F42UI11 Failed (078M) Error in P4210 A. Error in UBE log --UBE--[0]-- EventRule : Business Function F4211FSEditLine at line 479 for Event 13 in Section Detail Table Section has caused a memory violation. --UBE--[2]-- Finished with UBE Message Loop --UBE--[1]-- Total Pages processed are 1 --UBE--[6]-- Printing Object Value = 'ERROR:' --UBE--[6]-- Printing Object Value = 'EventRule : Business Function F4211FSEditLine at line 479 for Event 13 in Section Detail Table Section has caused a memory violation.' --UBE--[1]-- Before PRT_EndDoc --UBE--[6]-- Unsuccessfully Finishing Engine. Review UBE log for errors.
B. Error in CallObject Kernel log SELECT * FROM PD910.F0005 WHERE ( DRSY = '41' AND DRRT = 'S3' AND DRKY = ' ' ) No More Data Found /* Message in log indicates Blank Code is missing */ ERROR INFO JDEERR - ID= 28, Error= 018A - ..\..\Common\jdekrnl\runtime\RTK_DDVL.C, Line= 544
R47131 - EDI Inbound Purchase Order Change (this application is to update exiting sales order based on EDI table populated) |--- F4211FSEditLinePreProcess |--- ERROR INFO JDEERR - ID= 28, Error= 018A - ..\..\Common\jdekrnl\runtime\RTK_DDVL.C, Line= 544 (so this business functions returns Error meaning that it fails to create cache for sales order detail F42UI12) |--- F4211FSEditLine |--- CopySOInfoToWorkFiles /* this function copies cache in F42UI12 */ (So there is no cache created (missing source) as a result it is not able to copy it) : Since called BSFN B4211FSEditLine fails to return calling routine of R47131, Memory Violation Message will be written 'EventRule : Business Function F4211FSEditLine at line 479 for Event 13 in Section Detail Table Section has caused a memory violation.'
C. Cause of error : As described above error is coming in validation routine from F4211FSEditLinePreProcess
: Do not delete Blank UDC value (if you are not going to populate source files. e.g., szSalesReportingCode1) which is loaded in your installation.
Note:
In running P4210 for update mode, which shall issue error on screen however in batch deletion of blank UDC code can cause Memory Corruption (that is, NULL Pointer is being copied).
So do not delete Blank UDC for DD Alias SRP1 (UDC 41/S1), SRP2 (UDC 41/S2), SRP3 (UDC 41/S3), SRP4 (UDC 41/S4), SRP5 (UDC 41/S5), PRP1 (UDC 41/P1), PRP2 (UDC 41/P2), PRP3 (UDC 41/P3), PRP4 (UDC 41/P4) and PRP5 (UDC 41/P5).
Same issue can be occurred when you change default value for DD Alias which belongs to F42UI12 (Sales Order Detail Cache 2 (MBF)) table.
For detail, refer to <Document 1572856.1> - E1: 47: Case Study on R47131 ends in Memory Violation Error owing to missing settings and <Document 1115344.1> E1: 42: Open Cursor for Cache F42UI11 Failed (078M) Error in P4210
Example 7:
R30450 (Kanban Size Calculation) ends memory error when F3413 (MPS/MRP/DRP Summary File) : This issue shall be simulated any 64 bit platform
A. Representation error in PDF ERROR: EventRule : Business Function KanbanSizeCalculationGeneric at line 30 for Event 13 in Section Calculate Sizes has caused a memory violation. : For this example, 1st level business function which is called by R30450 is KanbanSizeCalculationGeneric so capture callobject kernel log and analyze it. Actual memory corruption is coming 3rd level BSFN B3003940 - GetAvgDailyDemandForKanbanItem (Get Average Daily Demand for Kanban Item).
B. CallObject Kernel log: B3003940 fails to return to calling routine so log ends eruptively.
C. Cause: Null Pointer is referenced as below, : Code Example:- /* Break In Code */ mnStartQty = I3003940_GetF3413Demand(hRequest,dsInternal, cDemandAggregationFlg, dsF3413.mrstrt,dsF3413.mrstrt); lpdsInfo->mnQty = mnStartQty; /* this line of code causes memory corruption when I3003940_GetF3413Demand() is NULL */ /* Break In Code */
D. Resolution: Refer to <Bug 16677551> STAUTS ERROR FOR FUNCTION FIXEDCONTAINERSIZEAVGDEMAND WITH NO RECORD IN F3413 : Possibly, you may check whether return value is zero or not as below, /* Break In Code */ if(MathZeroTest(&mnStartQty)) { lpdsInfo->mnQty = mnStartQty; } /* Break In code */
Known Issues and Bugs:
<Document 1237103.1> E1: 12: R12855 Ends In Memory Violation Error on Windows Server 2008 x64 <Document 632629.1> E1: 34: R3482 & R3483 Common Error Messages and Memory Violations <Document 639397.1> E1: 30: R30601 EventRule: Business Function BillOfMaterialIntegrityCheckT1 <Document 1064662.1> E1: 43: Possible Causes of Memory Violation in P4314 - Voucher Match Application <Document 1322258.1> E1: 47: R47011 Reads Memory Violation <Document 1272974.1> E1: UBE: Case Study on "MEMORY ALLOCATION FAILURE" Errors in EnterpriseOne Batch Applications <Document 1060818.1> E1: UBE: R98306X Ends in Error and Output is Showing Incomplete Data <Document 1179493.1> E1: BSFN: Call Object Kernel Errors Clarification - COB0000* which explains how JDE API.
Note:
Oracle's JD Edwards do not warranty any memory corruption issue caused by custom code
This note is to be updated without given any prior notice to indicate more case studies on this topic
This note is based on EnterpriseOne application release 9.1 and it's tools release 9.1
This note is created based on thin client configuration, which performs business function logic in your logic server
Additional case study can be added into this document without giving prior notice.