Fixing corruption in callbacks introduced by x86 changes #217
Conversation
| @@ -46,7 +46,7 @@ func eventSetInformation( | |||
| // for provider notifications. Because Go has trouble with callback arguments of | |||
| // different size, it has only pointer-sized arguments, which are then cast to | |||
| // the appropriate types when calling providerCallback. | |||
| func providerCallbackAdapter(sourceID *guid.GUID, state uint32, level uint8, matchAnyKeyword uintptr, matchAllKeyword uintptr, filterData uintptr, i uintptr) uintptr { | |||
There was a problem hiding this comment.
I'm a bit confused as to why we need to change these types. From PENABLECALLBACK it looks like they are ULONG and UCHAR, which should correspond to uint32 and uint8.
There was a problem hiding this comment.
So this is actually reverting the types to what they were before my initial changes. The comment above explains why they were that way. Go appears to give us all the callback variables as pointers, so if you leave level as a uint8, then part of the level gets shoved into matchAnyKeyword and everything becomes misaligned, causing the corruption.
There was a problem hiding this comment.
Ah, I think I see now, this is presumably something to do with how Go's callback code is translating the native args to the Go ABI?
|
Oh, one thing. Can you please certify your commit with the following command? |
Signed-off-by: Kyle Wojtaszek <kylewo@microsoft.com>
In my previous PR, when breaking out providerCallbackAdapter into separate 32 and 64 bit implementations, I changed the typing of the state and level arguments erroneously. These parameters should be treated as pointers, not as raw integers. This issue will cause the parameters passed into providerCallback to be corrupted.
Typically this is benign, however it causes a crash in the following scenario:
Under these conditions, the global provider map (in providerglobal.go) will not have an entry at index 0 (the index only ever increases, so the previous registering/unregistering of a provider leaves the 0 slot empty). The corrupted arguments into providerCallback will have an index of 0 instead of the correct index, and then providerCallback (provider.go line 69) will get a null provider and then attempt to update its state, causing a null reference panic.
This was missed in my initial testing, because for the test providers nothing is listening for the events, so the callback never gets called.