Glad that you figured it out.
Are you sure about the FireEvent problem being caused by that? I am not really convinced yet.
In the last callstack you posted, there seemed to be this series of events:
1) The server (engine) is in its normal game loop and calls IServerGameDll::GameFrame(). (frames #35 - #15)
2) This is hooked by SH, we get into the original function call, the gamedll's CServerGameDll::GameFrame (Frame #14, #13)
3) The gamedll does stuff, gets back into the engine to create a bot (Frame #12 - #6)
4) engine's CGameClient::Connect (frame #5) fires an event.
5) The FireEvent method was first hooked by SourceMod, so we get into SourceMod's hook manager.
SourceMod may have done something in its PRE-hook for the event, but we can't see that anymore in the call stack because it would have happened before the call to your PRE hook (ie. earlier).
In any case I don't see any reason to believe that the event it crashes on is being actively fired from sourcemod (ASSUMING that FireEvent would be called the moment sourcemod fires an event -- I don't know how the event management system works). It may have been modified by sourcemod in its PRE hook though (the passed object may have been modified or changed altogether with META_RETURN_*NEWPARAMS).
6) Your PRE hook gets called and crashes, apparently because the passed IGameEvent object has a weird vtable.
So my question would be:
What does SourceMod/its plugin do in its FireEvent PRE hook that makes you get an apparently corrupted object? Why doesn't it crash without your plugin if the object is corrupted?
Pretty weird.
EDIT: I have taken a look at SM's
event management code. It seems that the only reason I can think of at the moment that would lead to a crash in your hook would be this branch:
Code:
406 if (res)
407 {
408 gameevents->FreeEvent(pEvent);
409 RETURN_META_VALUE(MRES_SUPERCEDE, false);
410 }
ie.: the plugin tells sourcemod to stop the event from being fired (MRES_SUPERCEDE) and because nobody would otherwise take care of it in that situation, sourcemod frees the event object.
You can check if this is the case by checking for META_RESULT_STATUS == MRES_SUPERCEDE.
If that should really be the problem, it's not a good situation. It would mean that when sourcemod stops an event it basically invalidates the information about the event so no other plugins can use it. I have to say that it's hard to imagine a workaround with the current design except for
0) disable the plugin stopping the event
1) make sure your plugin registers the PRE hook first
2) convince sourcemod to remember the halted event object and free it in a post hook. that way other plugins would have a chance to take a look at it in their pre hooks
In an ideal world sourcehook would have cleanup hooks where one could do such stuff, which could be guaranteed to be called after post hooks (kind of post post hooks). Though that wouldn't be ideal either because it wouldn't come for free, developers would have to actively use it even though it wouldn't cause them problems to ignore the issue.
Linear Mode
