Just some preliminary things to get some more information:
Can you provide the full log file from a session where this crash occurs? Is the rate at which this happens (since you mention “after a while it crashes”) intermittent? The crash itself, as it is an access violation, is happening due to referencing a null pointer. With how you’re using your pointers, would it be possible to set up a check such as an IsValid? macro to make sure the pointers are referencing something before attempting to use them?
What do you mean by “intermittent”? The crashes ALWAYS happen after I change one of the pointers. Everything works fine, the graphic is changed and everything. The time after which it crashes is what changes from one session to another. But it always happens, unless I test the game in “Play In Editor” mode… oddly enough, it seems to NEVER happen in that case.
I usually check the validity of pointers before I use them when it is possible, but I’ll go and double check just to be sure.
Thanks again for your response and tell me if you need anything else.
I factor in my code the nullptr value for the SourceFlipbook variable inside objects of UPaperFlipbookComponent class.
This is because it seems like the most logical and simple way to make them just show nothing on screen. Also, it always seemed to work in any other case.
It would only be a problem if your logic references the SourceFlipbook variable for anything other than setting it to a new value while it is null. Referencing a null pointer ends up causing an access violation, forcing the editor to crash. Maybe you could set them to a Flipbook that only contains a blank frame. That should give the same result without setting it to null.
I will try both checking the code for parts where I try to access the pointer to use the object and using a blank flipbook.
But how is it possible that everything works fine in “Play In Editor” and not in “Standalone” or a packaged project?
This is just a curiosity, I may not actually need the answer.
Also, shouldn’t the crash report show the part of my code that causes the crash while trying to access the null pointer? I may be wrong, but the report seems to show only engine code.
I checked.
Everything I do in regards to flipbooks, I do on FlipbookComponents. The variable “SourceFlipbook” is referenced only when I want to change its value. Also, it is never done directly, always using the function “SetFlipbook()”. So it seems unlikely the crash is caused by accessing this variable.
I’m sorry, I don’t mean to bother you. If you are completely convinced that this crash has nothing to do with the engine itself, just say so and I will stop writing here. If that’s not the case…
Do you need more information on what I do with the flipbooks? Like how I sort them (with the translucency sorting priority) every tick or exactly the code I use to swap them inside the character?
I can provide you with the whole project code privately, if you need it.
P.S.
I’m insisting just because (and sorry if I repeat myself) I think the problem may reside inside the engine code itself since it does not happen in “Play In Editor” and no code of mine appears in the Bug Report.
I would be able to look into this further if you’re able to provide a project that reproduces the problem. As for your insistence that this is an engine issue, the fact of it only containing engine code is not indicative of anything as anything you call will also be calling something in the engine, as that’s how the engine works. You may not be calling these things directly but many things go on behind the scenes that you don’t see until stuff like this happens.
Yes, I didn’t mean to sound presumptuous. You are probably right and I’m sorry for having insisted.
Actually, it occurs to me that it could be an issue of garbage collection, related to the fact that, as you can see from the forum post, I use an std::map to store my pointers to Flipbooks. It would explain why the crash occurs only after a while and only when I move, actually trying to load a different flipbook onto the component.
Does this make sense? And how do I solve it? I’ve tried using a TMap<Animazione , TArray<UPaperFlipbook*>>, but the compiler says nested containers are not supported when I try to make it a UPROPERTY(). I guess it has to be a UPROPERTY() to get on the garbage collector’s radar? I hope this is the case, because without the UPROPERTY() macro, the crash is not solved.
Am I onto something here or am I just rambling?
P.S.
I can give you the entire project, if you need it, where do I send it?
Ok, I think I’ve solved the problem, though actually this is probably common knowledge…
I’ll explain anyway… there MIGHT be someone as stupid as me, in need of this information.
Thing is, if you need to use pointers to objects, be absolutely sure you are storing these pointers as “uproperties”, lest the garbage collector erase the object they are pointing to.
I thought it was sufficient to use Unreal Engine classes and containers, but I was wrong. They NEED to be uproperties.
My solution was rather complicated and specific to my project, but this is the gist of it.
Again, I know this is probably common knowledge and I’m sorry to have bothered the staff with this.
Thanks for the attention and keep up the good work.
I’m glad to hear you figured out the problem. It’s always good to learn something new. You’re correct, anything that you want to persist outside of the scope of a single function and need it to be valid, even normal variables, it needs to be a UProperty. Anything else will be culled once the garbage collector runs. It’s also good practice to always ensure your pointers are valid prior to using them, even if you are 100% sure that they will be.
