Lambda Causes Crash on Level Change

We found that having a BindLambda with a long (5.f seconds) timer would crash if changing levels using an OpenLevel, the crash was an TConsBitIterator where the array index was out of bounds. It appears that an outstanding BindLambda sitting on a timer, crashes the editor when it wakes up and you’ve changed to another level. Here was my code, the offending part in comments:

    if(IsDynamicSpawn) {
        if(MaximumSpeedConstant<40000.f) MaximumGovernedSpeed=40000.f; else MaximumGovernedSpeed=MaximumSpeedConstant;
//        FTimerHandle DynamicSpawnTimer;
//        FTimerDelegate DSSDelegate;
//        DSSDelegate.BindLambda([&]() {
//            MaximumGovernedSpeed=MaximumSpeedConstant;
//            IsSpawningTemplate=false;
//            this->SetActorEnableCollision(true);
//        });
//        GetWorldTimerManager().SetTimer(DynamicSpawnTimer,DSSDelegate,DynamicSpawnCollisionTimer,false);

We corrected this by making the timed routine a function. It no longer crashes.

Jeff, I’m sorry but I can’t do that. The link to the forums is currently returning a "cant establish secure connection type of error for me. Hopefully someone will consider this serious enough to look at it. It makes the BindLambda dangerous to use since any timer outstanding when a level load occurs might crash you, and that could happen often enough to make a game seem flaky. I didn’t try it in a build version, but it doesn’t like the editor. It’s rather difficult to debug when you get this. Hopefully someone will report it through official conventions eventually. If you could leave this here for now, possibly if anyone else hits this, they will have a clue where to look. Someone else might also see something that would show it’s not actually an engine bug and answer it in that manner.

Well, disregard my last comment, I was finally able to get to the bug submission form and fill it out.


We’ve recently made a switch to a new bug reporting method using a more structured form. Please visit the link below for more details and report the issue using the new Bug Submission Form. Feel free to continue to use this thread for community discussion around the issue.


Was it actually crashing inside the lambda invocation code, or was it crashing because you’ve captured a raw this pointer inside the lambda?

When you use the UObject function binding, the this you pass will be captured as a weak pointer so that it won’t call when the object is destroyed (or pending kill), the lambda won’t do that for you.

I can’t respond intelligently to that. Sounds plausible and in that case, it’s not a bug, but a constraint in setting up the lambda. I was under the impression that the necessary environment was copied by the &, so was counting on that resolving the necessary pointers. I hadn’t had any problems before converting it to the lambda from the conventional function call, and have no problems crossing levels now that I converted it back. Novice use of the lambda? Maybe.

I wasn’t able to track back in the dump to give much better evidence, I’m just not good enough with XCode to go back beyond a thread start.

I just realized that I apparently was remiss in not making it clear that this bindlamba was working perfectly as long as no level change (OpenLevel) was involved. So “this” is resolved unless a new level is opened. Does that clarify the conditions under which the hang/crash occurred?

Have a look at This will fix your issue in the future.