DAEMON-336 - If lCallbacks is empty don't call the fnCallbacks to avoid an ACCESS_VIOLATION #32
Conversation
…id an ACCESS_VIOLATION
| /* Call the user callback first */ | ||
| (*hObject->fnCallback)(hObject, WM_CLOSE, 0, 0); |
There was a problem hiding this comment.
Why is this inside the test of lCallbacks?
There was a problem hiding this comment.
This would also throw an access violation, i believe in the JVM.dll which is with a version i do not have pdb files for. I tested this on master with the current 1.2.5 fixes and this could also likely be caused by code from the java side of things. I do not have a good understanding of the issues here but i do know that lCallbacks was empty and that fnCallback would also raise an access violation. What are these meant to be calling? I presume something in the java, however i could not find any documentation, and this is the only "issue" to an otherwise well running service.
There was a problem hiding this comment.
As per my comment in DAEMON-336, I'd like to see the steps to reproduce this so I can dig into what is going on before applying any patches.
There was a problem hiding this comment.
Only adding the if is probably OK. Something like:
if (lpCall->fnCallback)
(*lpCall->fnCallback)(hObject, WM_CLOSE, 0, 0);
There are a bunch of place where we test the callback before calling it...
|
Any luck reproducing this issue or including changes for the upcoming RC? |
This is a more specific patch instead of removing the
apxHandleManagerDestroy();as suggested as a workaround. It seems that if there are no callbacks, this is empty and can throw an ACCESS VIOLATION. Instead ignore the callbacks if lCallbacks is empty.