• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

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