crash with endObject() help! :)

Game Engine Game Engine Support and Discussion
1

I was hoping that someone could point out some of the pitfalls with endObject() I am getting complete blender crashes when I use it in BGE or in UPBGE…but in UPBGE it is only versions after 0.1.8 I found no info in the api of any changes to it so I was looking at why it is causing crashes all of the sudden…

I have done no changes to this particular piece of code...my inventory..so it is a little important :)

I was just wondering if someone could point out some common issues maybe with using this function. I am aware it actually executes later so I tried moving the call to both the beginning and end of the code...both ways still cause crashes.

So, if anyone has advice I would be happy to hear it. I am not really interested in a 5th overhaul/re-factor of this piece of code.
2

If you try to end an object that isn’t active, you will get an error but blender shouldn’t crash. That’s all I came up with.

3

it works fine in current upbge

are you ending a object that has constraints?

4

if the active camera is (or a child of) the object you are ending, then it will crash. not sure how upbge handles this.

5

No, none of the above…it is an icon(I am deleteing an inventory icon) on an overlay scene…it is not parented to any other object…I am really stumped on this one…I have been messing with it all week(I go into BGE weekly to ensure it runs on official branch as well as UPBGE)…I can complete quests where the icons get deleted, but by any other means I get a crash…I will continue to look into it…either someone will have some insight or I will just figure out why it’s happening through magic :slight_smile:

If anyone else has any ideas I am open to them.
6

Can you upload the blend?

7

yeah, we are going to need atleast a script to look at.

8

Probably a material issue. 2.79 and the latest UPBGE are quite unstable for me where materials are concerned. Try with a very basic color-only material (no textures) and see if it is a material problem.

9

what does the console crash print out? I suspect* somewhere in your python is trying to access this object you ended leading to SystemError, gobj.invalid will come in handy

10

I suggest to report crashes to the bug-tracker.

11

that is my assumption as well, and the only thing that makes real sense…it is accessed across a few scripts, of which, I have disabled things to ensure that is not the case…this is also the reason I cannot simply upload the scripts…they are rather long as they deal with all the inventory, questing etc…I guess I could upload them, but I am way too self conscious for you guys to see my 12 if/else deep testing code :slight_smile: (joke) although there are a few places where I do have to do a few tests which I do not like…but sometimes it is the only way…I’ll keep investigating and I will look into that material issue…

is there a good pythonic way to see if anything is accessing this object or it’s properties?

12

store the object reference in a permanent variable, when you delete the obj, also set that variable to None.

13

I have worked with inventory overlay and scene changes extensively.

For me, a big problem was actually referencing an invalid scene to get an object (from perhaps a scene change), which raised a SystemError, and ultimately crashed Blender (even with try/except clauses). That took me two whole days to fix. I’ve also had invalid object references (references to objects that have been “erased” due to scene changes) for crashes as well.

You can try checking for invalid scenes and objects with, for example:


if scene.invalid:
    pass
    #Output/select/update the desired scene with, for example, "getSceneList()", etc.
#Or
if object.invalid:
    pass
    #Get a valid object, etc.

https://docs.blender.org/api/2.78b/bge.types.PyObjectPlus.html#bge.types.PyObjectPlus

This may or may not be your issue. Hope that helps.

14

Also, a copy of blendname.crash.txt would be useful. BGE dumps the C stacktrace on a segfault , and this can give an idea of where the issue is. On Linux it is put in the /tmp folder

15

I think I have made some small progress…in thinking anyway…I notice that the only objects that give me this crash are objects that have been added to the scene…all physically placed objects are fine, but if I use addObject() and later delete this object with endObject() I get the crash…

I am wondering if it is still possible to access the added objects lifetime variable and just set it to 1 in case any other script is trying to reference it…and ofc afterwards it would just end it’s own instance…

I will try to find the ‘Myrlea.crash.txt’…but I worry it is non exsistent…when I launch the stand alone player I get no errors and blender does not crash…but I will look.

OK, the file does not exsist, but…I find that the way the objects are added may be the case…

I use:

icon = ui_scene.addObject('INV_ITEM',own['slot_list'][temp],0)

but if I give it a time to exsist and not infinite it deletes without a crash

icon = ui_scene.addObject('INV_ITEM',own['slot_list'][temp],300)

???

16

I am now seeing what I think is a memory leak from main branch 2.79 and every version of UPBGE past 0.1.8…I need to verify though.
Error Totblock: 304
it almost looks like german :slight_smile: dead block…almost.

edit:
I get the same error with every version aside from 0.1.8,…

…in 0.1.8 I get the error but only with a value of 3…not too bad, no error would be better…

I am guessing it is an error of null object references in memory that do not exsist or something…but I have no clue tbh.

I need to probably repost this, but I cannot reproduce it in simple files…and there is no way I am going to upload my game…it is just too large at this point. So I guess for the rest of this project I am tied to UPBGE 0.1.8…which is fine…I will report it sometime this week when I can get a better idea of what is causing it.

17

In addition, I have had memory totblocks appear without crashes, but this case may be different.

As a side note, running Blender from the command line (for persistence) and print statements are great ways to trace code, depending on the situation.

18

I always, always… launch from terminal, I am on linux and it is always “on top” thus always visible. with as much code as I have running and as much code is touching other code(not a good thing, but needed in some cases) it is an absolubt must…

correction on my previous post I wrote I needed to “repost this” when I meant “REPORT this” english is so silly :slight_smile: