- July 25, 2012 at 2:39 pm #30929
I have downloaded PVRTexLib 4.04 (Build: 126.96.36.19958) to update a project that used an older version of the library. I have done some tests and came to the conclusion that while using the Windows 32-bit version of the library (both static and dynamic) there is some kind of memory error. Whenever the destructor of CPVRTextureHeader is called, I get an assertion failed on _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) [searching for the cause seems that there is a double delete somewhere deep in the library]. My operating system is Windows 7 64 bit and the compiler is Visual Studio 2010 Professional. A program as simple as the following crashes:
CPVRTextureHeader *sourceHeader = new CPVRTextureHeader(PVRStandard8PixelType.PixelTypeID,
CPVRTexture *sourceTexture = new CPVRTexture(&sourceHeader);
if (sourceTexture != NULL)
delete sourceHeader; // Calling this crashes the program. Otherwise, memory isn't freed and therefore leaks.July 26, 2012 at 11:56 am #36022
I’ve tested this and am not getting the same error – are you by any chance including our tools code in your project?
There was a bug in the original PVRTMap.h code which caused this issue, so if you’re including a directory which holds an old version of PVRTMap.h this might be the cause of the problem?
TobiasJuly 26, 2012 at 12:02 pm #36023
Hello Tobias,The only includes I have are the ones provided with the PVRTexLib libraries, and even in a fresh project it fails. Should I upload the project somewhere for you to check it?Cheers.July 26, 2012 at 2:18 pm #36024
As long as it’s a minimal test case I can have a look at that – you can email it to DevTech@imgtec.com if that’s easiest? Just make sure it’s not too large and contains no .dll or .exe files. If you have an alternative way of doing it that’s also fine. If you could also include copies of all the header files you have for PVRTexLib that might be useful too, in case there’s a release package problem we’re not aware of.
TobiasJuly 26, 2012 at 2:24 pm #36025July 27, 2012 at 10:25 am #36026
Ok, I see the issue now. When you create the source texture you’re deferencing the header again, making it a CPVRTextureHeader**, not a CPVRTexture, as I assume you meant to make it?
This is triggering the “CPVRTexture(const void* pTexture)” version of the function, which is designed to only accept raw PVR files streamed directly into memory – to allow users to use their own loading code without too much hassle.
Instead there’s a memory error being caused as it’s copying essentially nonsense data into the CPVRTexture.
In hindsight I should make the purpose of this function more clear, and maybe attempt to handle problems better (which I will try to do for next release) – but I expect you just meant to call it as (*sourceHeader)?
TobiasJuly 27, 2012 at 10:54 am #36027Hello Tobias,
Thanks for pointing the error – my C++ is getting kinda rusty after so much time with C#! I have tried changing it as you said but keeps crashing. Even if I do it without pointers
CPVRTexture sourceTexture(sourceHeader);When the execution reaches the end of scope and calls the destructors, it crashes with the same error. Is it because I’m not passing any texture data? Maybe there’s something wrong with my compiler settings?Cheers.July 27, 2012 at 2:19 pm #36028
You also need to add the line “#define _WINDLL_IMPORT 1” before you include the dll version of the library. Alternatively add it to your pre-processor directives as “_WINDLL_IMPORT=1”
As the same headers are used for the shared and static libraries, there’s no sensible way, currently, of throwing an error when a user links against the dlls but doesn’t add the import definition.
TobiasAugust 5, 2012 at 4:42 pm #36030
I was also having this problem until I found the solution here. Did I overlook this in the documentation? I don’t remember reading this but I could be wrong?Thanks!August 6, 2012 at 11:32 am #36031
This is actually listed in section 2.3 of the PVRTexLib user manual, though maybe it should probably be more prominent considering how many people have suddenly come to me with this bug!? We have to review documentation for our next release anyway soon, so I’ll see if we can change anything about how this issue is highlighted. I can also try to look into other methods of exposing dll functionality as well, but this won’t be until next year now unfortunately.