July 9, 2016 at 2:50 am #1933
So I have a superclass I use to represent the object hierarchy in a scene:Monkey123456789101112131415161718192021222324252627282930313233343536373839404142434445Class EntityPublicMethod OnUpdate() VirtualEndMethod OnRender(canvas:Canvas) VirtualEndMethod Update()OnUpdate()For Local child:= Eachin childrenchild.Update()NextEndMethod Render(canvas:Canvas)OnRender(canvas)For Local child:= Eachin childrenchild.Render(canvas)NextEndMethod AddChild(child:Entity)DebugAssert(child.parent = Null, "Entity can't belong to two parents")children.Add(child)child.parent = SelfEndMethod RemoveChild(child:Entity)DebugAssert(child.parent = Self, "Entity doesn't belong to this parent")'children.Remove(child)child.parent = NullEndMethod Remove()DebugAssert(parent, "Entity has no parent")parent.RemoveChild(Self)EndPrivateField children:= New List<Entity>Field parent:EntityEnd
It works beautifully, but if I add ANY other fields to the class that aren’t primitive types (ie, Ints and stuff), then there are all sorts of runtime memory access problems. For example, simply adding “Field obj:Object” with the other private fields causes the DebugAssert in AddChild() to fail – and if you look at the debugger for the child object in question, it’s not hard to see why.12345678AddChild:Void(child:siclib.Entity)Self:siclib.Entity=@00dd7074...child:siclib.Entity=@00dd7174obj:Object(null)children:std.collections.List<siclib.Entity>=@00dd7194parent:siclib.Entity=@00e8e7e4collisionMask:Int=@00e8e7e4
The field added by the subclass, collisionMask, somehow has the same pointer as parent does, even though they are completely disparate types – and while the subclass constructor assigned to collisionMask, nothing has assigned to parent. In fact, short of adding the additional field to the superclass, I changed nothing in the codebase from when it ran totally fine.
I haven’t been able to replicate this in a controlled environment, so it could be affected by something else in my project? I can provide any outputs that would help. It definitely seems like something about how the class is being compiled is broken.July 10, 2016 at 8:44 pm #1994
Any chance you can send me the project? Try and get it as ‘small’ as possible first please!
I doubt the fields are ‘overlapping’, but there’s a chance debugger output could be incorrect so that could be confusing things.
It could also be a GC issue. You could try enabling the #define BBGC_DEBUG 1 in modules/monkey/native/bbgc.h and rebuilding everything. This will cause the app to leak ALL memory allocated (so the bug better happen fast!) but it will bring up an error if a chunk of memory is incorrectly re-used.July 13, 2016 at 10:43 pm #2106
In case anyone has this problem in the future, deleting your build folder and rebuilding works, and hopefully it won’t be long until a fix is live. Thanks Mark!July 14, 2016 at 9:49 pm #2145
This turned out ot be a ‘spaces in filename’ build issue, but was kind of fun to find.
The main problem was that mx2cc wasn’t recognizing a file had changed so wasn’t rebuilding it.
But each time I tried to add something to the monkey module to do some testing, this was enough to trigger a rebuild! So I ended up having to add a new foobar field after each modules update – I ended up with about 5 foobars before it clicked what was happening…
For a while it seemed like the ultimate heisenbug – each time I tried to measure it, it very predictably disappeared!
You must be logged in to reply to this topic.