Heap corruption when accessing texture matrix

[Ico]

Alright, finally some dumb question to ask here. Just can't find the bug.

Code: Select all

ISceneNode *node = _smgr->addCubeSceneNode();
node->getMaterial(0).setTexture(0,_driver->getTexture("test.bmp"));
node->setMaterialFlag(EMF_LIGHTING,false);

So far, everything simple and working. I do a simple main loop drawing everything etc. and then drop my device.

But now, if I try to access the texture matrix (get or set doesn't matter) Irrlicht creates one (in case none exists yet) but still causes a heap corruption breakpoint once dropping the driver (actually while deleting TextureMatrix within SMaterialLayer).

Either line will trigger the breakpoint later on:

Code: Select all

node->getMaterial(0).setTextureMatrix(0, matrix4());

core::matrix4& texMat = material.getTextureMatrix(0);

Accessing/modifying the matrix (after second line from above) works like it should too.

(Using latest unmodified SVN files)

[hybrid]

Yeah, Windows C-Runtime hell. Simply make sure that all parts of your app use the same dll to link against and it won't happen. Usage and memory management of the matrices is ok, it's just that the matrix is allocated in your application (due to inlining) and freed from the library (due to the device destructor).

[Ico]

Everything uses the static runtime (release/debug) files as well as the same libs. Tried adding

Code: Select all

node->getMaterial(0).setTextureMatrix(0, matrix4());

to example 8 and got the same error.

Maybe something went wrong converting the projects to vc 2008? (Only one warning related to changed web deployment only.) Don't have vc 2005 installed atm so maybe someone could test this there (and maybe under 2008 too)?

[vitek]

Everything uses the static runtime (release/debug) files as well as the same libs.

That doesn't change anything. If you use an Irrlicht DLL, that DLL and your executable both need to link the same shared runtime. It must be shared.

Travis

[Ico]

Finally found some time again ... yeah you're right. It's one of the too easy solutions you sometimes just don't see.

Simply forgot the fact Irrlicht is still linked dynamically so the runtime is running in its own memory area while that isn't the case when linked dynamically... arr... I hate those moments. Thanks anyway.

[BlindSide]

I'm having the exact same issue. Why do you need to store the texture matrices in the heap? Maybe this should be modified to prevent people from encountering this obscure problem, and having to fix it everytime.

Cheers