Bug in PVRTexLib?

PowerVR Insider
1

I have downloaded PVRTexLib 4.04 (Build: 2.10.90.5358) 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,
		1024,
		1024,
		1,
		1,
		1,
		1);
 
	CPVRTexture *sourceTexture = new CPVRTexture(&sourceHeader);
 
	if (sourceTexture != NULL)
		delete sourceTexture;
 
	delete sourceHeader; // Calling this crashes the program. Otherwise, memory isn’t freed and therefore leaks.
2

Hi r2d2rigo,

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?

Thanks,

Tobias



3

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.
4

Hi r2d2rigo,



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.

Thanks,

Tobias





5

Hello Tobias,


I’ve packed the project with the headers and libraries that give the problem. Since it has a DLL inside, you can download it from https://dl.dropbox.com/u/6782932/pvrtest.zip

Cheers.
6

Hi r2d2rigo

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)?

Thanks,

Tobias



7
Hello 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

	CPVRTextureHeader sourceHeader(PVRStandard8PixelType.PixelTypeID,
		1024,
		1024,
		1,
		1,
		1,
		1);
 
	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.
8

Hi r2d2rigo,

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.

Thanks,

Tobias



9

Thank you Tobias, it works like a charm!

10

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!
11

Hi Zoid,

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.

Thanks,

Tobias