If I get the assert BPrivate::block* BPrivate::superblock::getBlock(): getNumAvailable() == 0
what does that actually mean? The app is only using 11MB of RAM so it can’t truly be unable to find an available block. Does it indicate a memory leak?
I also hit a GPF trying to delete a pointer that seems to have 0xdeadbeefdeadbeef as the address, so I assume that’s something ugly happening - heap corruption?
So far I tried running with malloc_debug but I don’t see any of the symptoms there. I haven’t gone through the “Advanced Use of malloc_debug” section yet. Is that my best bet?
Experts may give you more details or correct me, but it looks like use after free. The 0xdeadbeef marker is used on malloc_debug to fill freed memory to better catch this case. The assertion I think I’ve seen it when some memory management structures get corrupted due to writing on freed memory or outside the allocated areas, like past an array bound.
Thanks, @madmax - that does match the behavior I’m seeing. I was able to track down -where- the problem is now, the trick is to figure out -why- it’s happening.
Try working backwards from where you delete that pointer. Where was it created and what happened to it during its life ? Maybe you can get some clue of why it is disappearing
Well, it turns out I wasn’t deleting a pointer directly - I was accidentally, in one particular case, returning the wrong pointer. Then that pointer was getting deleted and replaced with itself - which had just been deleted.
So, use-after-free, but in a bit of a roundabout way. Good times!