Weirdest bug I've ever run into.

[Austin J]

I have a resource manager that holds a vector of pointers to texture objects. I created a texture somewhere else on the heap, and somehow its pointer is in the middle of my vector of textures. If I was adding it to the vector on accident, (which would require some serious incompetence on my part) it would be at the end of the vector, but no it's randomly a bit before the middle element. I'm really amazed by this. There should be no possible way that texture pointer is getting added to that particular vector(or any for that matter).

Has anyone run into something like this? I simply can't wrap my mind around how that pointer could accidentally appear in the vector like some freak accident.

[LB]

How are you "creating" the texture object? Maybe the underlying library optimizes and realizes that the textures are the same and so re-uses the existing texture which is already in your vector.

[Austin J]

I'm using SFML, my texture class mostly just encapsulates sf::Texture. The texture constructor loads from file, with some better error checking/logging and determines some other information which should be irrelevant. (The sf::Texture member is not a pointer by the way)

The texture I allocate away from the vector is not loaded anywhere else, so assuming SFML can do what you say, that couldn't be it.

Thank you for thought all the same. Another note, I do add the textures to the vector and allocate the free one in the same code block, that's probably note worthy information I should have mentioned. If that does have a role, it's most likely nitty gritty stuff that I have no clue about at all. (Not going to lie I have no actual clue how stacks and heaps work under the hood)

This bug isn't a real threat, as the free texture was actually just me trying to test something, so I can simply remove it. This seems like a very nice learning opportunity however, so I would like to solve it.

[LB]

That's really weird. It must be something else. There's no way to tell without seeing the code unfortunately...

[Lachlan Easton]

You say you have a vector of pointers to textures, not a vector of textures. The textures that the pointers point to could be placed anywhere in memory.

[Austin J]

Lachlan, the fact that I can do anything with that element however is weird. The fact that I can point an iterator to that texture, then dereference the iterator, then dereference that pointer, is very odd.

[Lachlan Easton]

I really don't think I follow. As far as I can work out this https://drive.google.com/file/d/0BxLvyrTG8Z1QT1Z6NTQ0aS1CNDg/edit?usp=sharing is what you're describing.

[Austin J]

I was on the same track of thought you are on Lachlan, but then I realized that shouldn't matter. My vector shouldn't be able to touch that texture object on the heap without a pointer to it, no matter where it is.

However, actually I think you're still semi-right. I was just looking, and it turns out that not only does this rogue texture somehow get in, but one of them gets replaced.

So actually, it appears maybe what's happening is this texture is getting in their, somewhat like your image shows, and is kicking out one of the elements that should be their. The pointer in the vector obviously wouldn't care because it'd still just be pointing to a texture on the heap.

[LB]

It sounds like you're passing pointers by reference unintentionally and having them get assigned to...

[Austin J]

@LB

I'm not passing pointers by reference literally anywhere in the entire program.