X0010GetNextNumber gets intermittent Access/Memory Violation

[Carl]

I keep getting an intermittent memory violations when I call X0010GetNextNumber. I’m calling it repeatedly inside a loop to obtain a key for each detail record I want to write. The weird thing is, sometimes the process works!

R49T90 calls B49T0300, which calls B49T0500, which reads the F49T60 and calls B49T0600 - Import Inbound Voucher XML, whenever a voucher record is found. I am trying to write additional information for the voucher records from parsed XML as it comes through on the F49T60; F5547001 header and F5547002 detail. The program was originally set up to insert the F49T60 & F47041/42/44 table records in one paragraph

The program originally called had paragraph I49T600_insertTables which called I49T0600_populateTableColumns, and then performed the JDB_InsertTable command for F49T60 & F47041/42/44 tables. I still have that original code in place, but I have inserted another paragraph between the Populate paragraph and insert commands. It loops through the XML, writing F5547002 records. As it does this, it needs to fill in a unique key, set up in Next Number 56 with index 2. Sometimes this fails on the second call to X0010GetNN, and all records are rolled back. The lpdsInternalPtrs are linked to LPDSX49T0300INTPTRS, so I dare not alter anything in it.

I have tried putting the F5547002 Next Number lookup and insert in a separate function, but that didn’t work. I have tried two version of the X0010GetNextNumber call:

CALLIBFRET(idReturnValue,I49T0300_CallObj(_J("X0010GetNextNumber"), lpdsInternalPtrs->lpBhvrCom,lpdsInternalPtrs->lpVoid,(void *) &dsGetNextNumberParms));

<and>

idReturnValue = jdeCallObject(_J("X0010GetNextNumber"), NULL, lpdsInternalPtrs->lpBhvrCom, lpdsInternalPtrs->lpVoid, &dsGetNextNumberParms, (CALLMAP *) NULL, (int) 0, (JCHAR *) NULL, (JCHAR *) NULL, (int) 0);

I have tried “casting” the parameters. I suspect the problem may have something to do with the JDB_InitUser and JDB_FreeUser which are called at the beginning and end of the program to maintain all of the records written within the transaction boundary. I apologize for the long winded explanation. I can't seem to put my finger on it. The debug log just goes out to never-never land (into the calling programs) after the X0010GetNN receives the Memory Violation. The documentation on the proper use of TP boundaries seems sketchy to me. I assumed X0010GetNN has its own.

__________________________________
Report output =
EventRule : Business Function parseTransInboundTransmissions at line 1 for Event 13 in Section Process Transmissions has caused a memory violation.
__________________________________
jde.log=
6000/2384 MAIN_THREAD Fri Jul 24 15:06:47.076003 zdrv.cpp373
Creating XML Session

6000/2384 WRK:Starting jdeCallObject Fri Jul 24 15:06:47.826119 XMLRequest.cpp1260
ICU0000017 - ICU CodePage for 1252 is ibm-1252.

6000/2384 WRK:Starting jdeCallObject Fri Jul 24 15:06:48.529035 ntexhnd.cpp101
Exception code: C0000005 ACCESS_VIOLATION

6000/2384 WRK:Starting jdeCallObject Fri Jul 24 15:06:50.764001 ntexhnd.cpp151
====> Exception occurred with call stack:

ExpInterlockedPopEntrySListFault+0 C:\WINDOWS\system32\ntdll.dll
0000:00000000

Last Debug Time Stamp: Fri Jul 24 15:06:50.779
INFO: Done setting IPC Handle State structures to abandoned. Process exiting. iParam: 0000001960
__________________________________

PS Search for "***CLN" in the debug.log to see where the process "goes south". Thank you in advance for any hints/tips that can be offered.

 

[Carl]

By Jove, I think he's got it!

I inserted include member b98220c.h and called OMWGetNextNumber. This worked! OK, so now I have narrowed down the culprit to potentially being the passed parameters. I do not want to use the OMWGetNN call in production. So…

I had JDEBFWINAPI DDID_GetNextNumber in the include module. I removed that and altered SIZEOF parameter in the MEMSET command
FROM:
memset((void *)(&dsGetNextNumberParms),(int)(_J('\0')), sizeof(DSD0000065));

TO:
memset((void *)(&dsGetNextNumberParms),(int)(_J('\0')), sizeof(dsGetNextNumberParms));

So far, so good. I’d like to thank everyone that downloaded the jdedebug.log and glanced at this issue. I did have the original code working for extended periods, only to fail again. Hopefully, this will keep working. Thanks again. I will continue testing my fix…

 

[Carl]

False alarm. It's happening again every once in a while. Back to the drawing board...

 

[Carl]

When checking the status of the Xerces XML parser, be certain to also check the number of nodes is greater than zero. Also be certain to free the element array.

Doing this resolved my memory violation.