debugging zombie kernel

BOster

Legendary Poster
Not sure. Was just about to ask if anyone knows if a jdeStore/Remove call that fails gets logged anywhere on the ES server.

I would think though that the jdeStoreDataPtr call would be the one to fail, not necessarily the jdeRemoveDataPtr. So even in the I3101250_GetWorkOrderInfo code I would think that a handle would not be returned by VerifyAndGetWorkOrderMaster and subsequently jdeRemoveDataPtr would never be called in I3101250_GetWorkOrderInfo. But as Craig pointed out it appears to be the MathCopy that caused the zombie and the only MathCopy in I3101250_GetWorkOrderInfo is right after jdeRemoveDataPtr and the only way I can see that MathCopy would segfault is with a null ptr which would mean a jdeRemoveDataPtr failure.

All speculation on my part, it could still be anything I guess - don't get tunnel vision on jdeStore/RemoveDataPtr.
 

nkuebelbeck

VIP Member
i executed VerifyAndGetWorkOrderMaster with id tags return for both f4801 and f4801t a bunch without clearing the pointer (on my fat client).

at 999 it goes to zero and this appears in the jde.log file

1984/4032 WRK:Starting jdeCallObject Thu Jun 02 10:01:23.617000 Jdb_utl1.c2644
JDB9900600 - Failed to store value, maximum exceeded. Probable cause is forgetting to call jdeRemoveDataPtr()
 

BOster

Legendary Poster
i executed VerifyAndGetWorkOrderMaster with id tags return for both f4801 and f4801t a bunch without clearing the pointer (on my fat client).

at 999 it goes to zero and this appears in the jde.log file

1984/4032 WRK:Starting jdeCallObject Thu Jun 02 10:01:23.617000 Jdb_utl1.c2644
JDB9900600 - Failed to store value, maximum exceeded. Probable cause is forgetting to call jdeRemoveDataPtr()

Good to know. So I guess if that was the culprit you would expect to see that msg in the ES log.
 

nkuebelbeck

VIP Member
This thread is getting a little sidetracked, but does anyone know if the 999 limit of pointers stored is process specific or shared across all processes?
 

craig_welton

Legendary Poster
I'm gonna bet by process. Otherwise some runaway could bring down the entire system.

more thought ...

actually I believe this is by login session
 
Last edited:

craig_welton

Legendary Poster
partly. but a user can have multiple user handles. I'm thinking it's stored in the HENV (environment handle) created at login. A HUSER will have a reference to the HENV.
 

BOster

Legendary Poster
Your probably right, it probably is by the environment handle. Regardless, I just think of it as per user's Enterprise Server Session. Basically each user session gets 999. I did some testing a long time ago and a run bug in an A/R application for example can theoretically take down sales orders for a given user login. That is why I am always EXTREMELY careful with jdeStore/RemoveDataPtr (actually I try to avoid as much as possible) since a bug in one little piece of code can have an effect in a completely unrelated application.

The way I3101250_GetWorkOrderInfo is coded (at least on my release) is extremely fragile - it has the potential to return before it ever calls jdeRemoveDataPtr on all the returned pointers.
 
Top