I have a custom gamemode that make the match play by round.
At the beginning of each round, I’m calling HandleMatchHasStarted to properly reset & restarting my round without reloading the level.
In 4.7, evertyhing was workign as expected. Since 4.8, I have this issue:
Assertion failed: !DelegateInstanceInterface->IsSameFunction(*InDelegateInstance) [File:c:\unreal engine\4.8\engine\source\runtime\core\public\delegates\DelegateSignatureImpl_Variadics.inl] [Line: 1003]
The issue is raised on the 2nd Round.
The code is doing:
AGameMode::HandleMatchHasStarted()
which call GameSession->HandleMatchHasStarted();
which set StartSessionCompleteHandle = SessionInt->AddOnStartSessionCompleteDelegate_Handle(FOnStartSessionCompleteDelegate::CreateUObject(this, &AGameSession::OnStartSessionComplete));
On the first call it’s working as expected, but on the 2nd call the assertion failed.
It seems that the old delegate and the new one is not the same, but I can’t get what’s wrong.
The error message that you provided matches a crash that we have received multiple reports about. We believe we have a fix in place for this crash, but do not yet have any solid repro steps to test with. Would you be able to provide some additional information about how you are setting up and using your delegates, or would it be possible to take a look at your project?
In fact, it’s the Engine code that is setuping the delegate:
It’s in : GameSession->HandleMatchHasStarted()
In my code,the delegate is not cleared between 2 calls to HandleMatchHasStarted() as this state is called twice without calling endmatch (which clear the delegate).
Just try to call this function twice with an OnlineServices Setup.
I hope your can put a repro in place with thoses informations.
I was encountering a similar issue (with a different delegate), and after a while of struggling, I finally figured out that my problem was simply that I was binding to the delegate twice. Since this is happening on the second round, this is probably your issue. Either call Remove() at the end of the first round to unbind the first delegate, or just add a condition to not set the receiving delegate a second time.
Very sorry for the delay on this post. Checking into this a little bit further, it looks like the Engine itself is calling HandleMatchHasStarted(), and then your custom GameMode class calls it again (or vice versa). Ideally, the call to this function from the Engine should be sufficient. If that is not the case, that is something else we may have to take a look at.
Our concern at the moment is not that the delegates are different, but that it may be trying to bind a delegate that is already bound. The code does appear to be trying to clear the delegate when it is complete, so it looks like there may be a code path that isn’t properly triggering the delegate. What platform are you working on currently?
I know the root cause of the issue.
It’s a change that has been implemented in 4.8 so I had to rework on my source code to manage this new “base behavior”.
So on my side I fixed the issue.
I’m working on a PC Platform. I just called multiple time StartMatch before endmatch because I was using this to manage Round inside a match.
It’s was working perfectly in 4.7 because there was no default behavior for those function (see link in 3rd comment).
So the delegate is already bind at the first Call (1st Round) and call again at the 2nd Round (without end game - means no remove binding).
I tried reproducing this using various multiplayer options by setting up a keypress to call HandleMatchHasStarted(), then pressing that key multiple times. It did not trigger the assertion for me. Would it be possible to see the code for your custom GameMode class?
We have not heard back from you for a few days. Are you able to provide any additional information that would help us repro this issue? Since you have found a solution for your own project, I will mark this as resolved for internal tracking purposes, but I will continue to poke at this issue periodically to see if I can repro it. If you do have any additional information that would help, please feel free to add a comment to this post and re-open it.
Sorry I had no time to get a repro available.
There is a problem somewhere as I’m not alone to have this issue but it’s not easy to repro ^^
If I can get one I will submit it.
[Apologies if duplicates of this get posted; answerhub seems to be functioning strangely and I’m not sure if my posts are showing up].
I get this same error. I had a working game in UE 4.7, upgraded to 4.9, fixed C++ compile errors, tried to play and immediately got this error.
I am using a C++ game mode and then inheriting from that in a blueprint game mode. The game modes do not do anything complicated. Basically just setup some debugging stuff.
I tried re-parenting my game mode so it inherits from GameMode and does not use my C++ game mode. It still crashes on startup.
Further investigation suggests that for me it is not the GameMode that is the problem. Instead, when I use Event Begin Play in the player controller, create some UMG widgets (including using UserWidget), and then call AddToViewport in the player controller begin play it crashes with this error.
Digging further helped me realize that I was calling AddToViewport twice: once in the player controller after crating my UserWidget and another time in the OnConstruct event of the UserWidget. Obviously that was something I was doing wrong, but it would be really nice to have a better error message or not crash.
Thank you for the additional information that you provided. I was able to reproduce a crash that provided the exact same error message that mentioned in his initial post. I am not sure that this is the exact crash that was experiencing without being able to compare callstacks, though. However, it is most likely very similar. The fix that I mentioned in my first comment did not prevent this crash, so I have entered a report about this crash to have it investigated further (UE-20873). For a workaround, make sure that any particular instance of a UMG widget is only added to the viewport once.
, if you get a , would it be possible to get the callstack for the crash that you were initially experiencing? Don’t worry about it if you can’t.
I can’t get the stackstrace as I fixed this in my code to not “crash”.
Clearly, from reading, it’s the same issue. Something that you are calling twice that should not be call twice without another function call in between that “clean the stuffs”.