Crash: UPrimitiveComponent::UpdateOverlaps accessing Array of length 0

Heya,

In my code, at one point I call SomeChildActor->ChildActor->SetActorEnableCollision(false);

This causes a crash because the UpdateOverlaps functions some time down the chain accesses an array of 0 length, as seen in this debug screenshot:

I solved it on my end by adding a Num() check beforehand, but you might have a different solution in mind.

Best regards,
Damir H.

As I know UPrimitiveComponent::UpdateOverlaps method was changed in 4.8. Most probably this bug is already fixed. Try the latest 4.8 preview build to check it out. Please let me know when you check it

Heya,

Thanks for the info, I’ll be sure to check it out.

Hi DamirH,

I tried to reproduce the issue that you described but was unable to do so. Were you able to try this in 4.8 and saw the same results? If so, could you provide more information about how you are setting this up?

Yup, I managed to reproduce it (This time, OverlapIdx was 4, ArrayNum was 0). There is a very specific series of steps and conditions I do to reproduce it so hopefully this’ll help you narrow it down. Throughout the text I will add code snippets and I’ll group them into pastebins with relevant, but not necesarily same-file information.

First of all, the context is enemies wielding weapons and me disabling collision on those weapons when the enemy dies. The weapons can be melee or ranged, and are child actor components.

Perhaps significant is the fact that I create and populate those child actors via the construction script, as seen here.

Now, my ranged weapons have a child actor component which is the projectile (So basically my enemy’s child actor has a child actor). I set that to any object of the ProjectileBase class in my blueprint. The ProjectileBase header and implementation can be seen here.

Now, when my enemy dies and goes into ragdoll, I don’t want him flailing around because he’s colliding with his own weapon. This is the code snippet that turns off the weapon collision.

The error happens at line 12 - trying to turn off the collision of the projectile, but only, and only if the ranged weapon / projectile overlaps the melee weapon. I accidentally forgot to attach them both to the right hand and the bug didn’t occur - if they don’t overlap, nothing bad happens.

I hope this is enough for you to replicate it, or at least get a better understanding. Let me know if I can help in any other way.

Thanks for providing the code you are using. I am attempting to get a project to build using your code (there are some references to code that wasn’t provided, I need to comment out those references and make sure it still works correctly to reproduce the issue), and then will try to simplify the project as much as possible while still reproducing the issue.

Would it be possible to get the callstack provided by the crash reporter when running the project in the Editor?

Hey ,

Unfortunately I am also sporting this awesome bug:

But VS should provide the stack at the time of a break so it should be fine, I’ll get to it first thing in the morning when I get back to the office. Alternatively if the build I have at home can reproduce the bug I can have the stack in an hour.

Also, given the referenced code (I only included relevant bits) I will try and make a small project that just replicates the bug for you. Will get back asap.

Edit:
Also if you mean the weapon component code, I included pastebin links to those at the bottom of the first link. Here they are:

Melee weapons .h: // Copyright Damir Halilovic 2014 - 2015#pragma once#include "GameFramew - Pastebin.com
Melee weapons .cpp: // Copyright Damir Halilovic 2014 - 2015#include "ProjectWa.h"#include "Da - Pastebin.com

Ranged weapons .h: // Copyright Damir Halilovic 2014 - 2015#pragma once#include "GameFramew - Pastebin.com
Ranged weapons .cpp: // Copyright Damir Halilovic 2014 - 2015#include "ProjectWa.h"#include "Ra - Pastebin.com

Hey ,

Creating the test project might take a bit, but here’s the callstack:

Line 349 in ProcessDamage is line 12 in the last code snippet I provided in my original explanation.

Also, for what it’s worth I personally think this can be traced down to ChildActorComponent, it’s always been an odd beast and I am using it in a very colorful manner.

Best regards,
Damir H.

I believe I am very close to completing the set up to reproduce this issue, but have one more question. How have you declared the Weapons array that you are iterating through in the loop that is causing the crash? The initial declaration I used for that array did not allow me to actually specify any weapons in the Blueprint I created from the enemy class.

Hey ,

Sorry for leaving that out. I imagine you’re talking about the Weapons array found in this snippet. That is actually a Map. Here’s a pastebin with comments on how it’s all done.

It’s a tad bit convoluted, I hope this doesn’t throw you off too much. Basically, Weapons is a map so that I can quickly access the weapons with a GetWeapons(FWeaponSlot Slot) function. The FWeaponSlot is just the socket it attaches to + whether it’s melee or ranged. Having the weapons in a map speeds up accessing like this.

The map itself is initialized by the CombatComponent (where all of this resides), but the caller for the InitializeWeapons() function is the EnemyCharacter, as you can see that weapons require the owner’s skeletal mesh to initialize (so they know where to look for their respective attach socket.

Hey , any news on this? Did you manage to get the project running?

Sorry, I got involved in a few other issues. I’m hoping to be able to get back onto this later today or tomorrow.

Last week turned out to be a bit crazy for me, and this week doesn’t look much better. I did have some time to look into this again yesterday, and I still think I’m close, but I am still missing some little thing that will allow me to reproduce the issue.

Would it be possible to take a look at the entire project? If I can see it happening in your project, I may be able to work backwards from there to determine where the issue is coming from.

Hey ,

I just talked to my higher ups and I can send you a striped down version with the bug through a private channel if that’s ok. If you can give me an email address to send the link to I can have the build by tomorrow morning.

Best regards,
Damir H.

If you have a private DropBox, Google Drive, or similar that you can upload a zip file to, you can send me a link via [private message][1] on the forums.

If that isn’t possible and you need to attach a zip file directly to an email, go ahead and send me a PM on the forums and let me know, and I will get you my email address.

I’ll put it up on Dropbox and PM you as soon as it’s up.

Best regards,
Damir H.

Thank you for providing the test project. I have been able to narrow down where the the issue is occurring. Now I just need to figure out why this is happening with the particular setup that you are using with the character.

Wooo! Progress! I feared the whole day that you might not be able to reproduce it. I think I am the only person in the world who had this issue. :stuck_out_tongue:

I was able to reproduce the issue right away. I think it is just that you have a very unique character set up, and you are perhaps doing something we had not anticipated. I spent a big chunk of today slowly working through the source code that is being run to find out where things were going wrong. Now that I know roughly where that is happening, I am hoping I can start picking stuff apart to find out why it is going bad in this case.

I wasn’t aware that my setup was that exotic. Am I perhaps doing something wrong?