Imagination PowerVR SDK Blog

PVRTexLib Crash with Visual Studio 2015

pvrtextool

#1

I updated from an old library to the latest 4.14.6 (using DLL, not static).
Since a lot has changed, I switched to the new “Transcode” function.

Running the code in either Debug, Release, 32 or 64 Bit will always result in a crash.
It turns out it will crash while deconstructing CPVRTextureHeader.
I made an all new project and reduced it to a bare minimum:
[pre]
#include "PVRTexture.h"
using namespace pvrtexture;

int main[int argc, char *argv[]]
{
CPVRTextureHeader pvr_header;
}
[/pre]

Debugging will hit a break point with:
HEAP[test.exe]: Invalid address specified to RtlValidateHeap( 00D20000, 00D35B58 )

Stack is:
~CPVRTMap -> Clear() -> ~CPVRTArray -> delete []m_pArray

I am running Visual Studio Community 2015 on Windows 10 64 Bit.
I tried it with the last 14.0.23107.0 D14REL, and the new Update 1.


#2

Hi Pierre,

Thanks for reporting the issue. I’ve filed it as BRN58175 in our tracker. The PVRTexTool lead is now investigating.


#3

Thank you Joe for the reply, I am not sure if it is really a bug or if something on my side is wrong.
But I can’t double check and also can’t proceed with updating my tools if it crashes. :slight_smile:

But: The transcode also decodes PVR, is there a performance or quality difference if I use the decoder function instead (from Utility`)?


#4

[blockquote]I am not sure if it is really a bug or if something on my side is wrong.[/blockquote]
From our initial analysis, we suspect this is a bug. The PVRTexTool lead is investigating now.

[blockquote]The transcode also decodes PVR, is there a performance or quality difference if I use the decoder function instead [from Utility`]?[/blockquote]
PVRTexLib decompresses PVRTC1 images with the PVRTDecompressPVRTC() function in PVRTDecompress.h. PVRTC2 images, however, use a different decompressor that we do not provide as source.


#5

Thank you Joe for the update and info about the inner workings of the decompressor function.


#6

Some time has passed and I have no tried the new PVRTexLib 4.15.0.
I still see the very same behaviour, crash while the object is deconstructed.

Can someone please look into this?

On a side node, it seems the very nice and slim PVRTDecompress.h/cpp now contains more dependencies. Any reason those were added? It now uses uint8 instead of PVRTuint8, std::max instead of PVRT_MAX, assets::ETC_MIN_TEXWIDTH instead of ETC_MIN_TEXWIDTH (showing as deprecated).
I would see and like to see this single file as a easy drop in, if you had lots of dependencies it becomes a burden.


#7

[blockquote]Can someone please look into this?[/blockquote]
I’ll discuss the issue with the TexTool lead.

[blockquote]Any reason those were added?[/blockquote]
I agree that the code should have fewer dependencies. I suspect this was an oversight rather than a conscious decision. I’ve filed a bug report in our tracker for this:

[ul]BRN58442: SDK Framework: Reduce PVRTDecompress.cpp header dependencies[/ul]


#8

[blockquote]Can someone please look into this?[/blockquote]
The PVRTexTool lead did not have the opportunity to investigate this issue before our 4.0 SDK release. We will address the problem in a future release.


#9

Thank you Joe for the update.
I am really looking forward and need the update to continue our tool chain.
If there is some fort of beta version, I would love to download it privately to give it a try. (I do not need an installer)

Thank you,
Pierre.


#10

Joe, any news if the issue could be reproduced and be resolved?
When will the next SDK version be made available?


#11

As far as I can see the problem is that the destructor of CPVRTextureHeader isn’t specified. This makes VS 2015 automatically create it inline and since CPVRTMap/CPVRTArray is a template it is inlined too. So CPVRTMap is created inside the CPVRTextureHeader constructor in PVRTexLib.dll using one heap and destroyed in client code potentially using another. Placing an empty destructor in CPVRTextureHeader and keeping it inside PVRTexLib.dll should solve the issue.


#12

Thank you Markus, makes pretty much sense.
Now I hope to the Developers can build a new library so I can finally update my tool chain again. :slight_smile:


#13

You can work around the issue by simply not creating a CPVRTextureHeader directly. Just create a CPVRTexture and use the setters it derives from CPVRTextureHeader to set it up. CPVRTexture has a destructor implementation inside PVRTexLib.dll so it doesn’t have the issue.

Edit: example:

[scode lang=“C++”]
CPVRTexture dummy;
PVRTextureHeader & header = dummy;

header.setWidth(256);
header.setHeight(256);
header.setNumMIPLevels(1);
header.setPixelFormat(PixelType(‘r’,‘g’,‘b’,‘a’,8,8,8,8));

CPVRTexture src(inputHeader);
[/scode]

This doesn’t crash for me.


#14

Hi Markus,

Thanks for sharing your findings and workaround. I’ll pass this on to the TexTool lead. Seems like an easy problem to solve for our next release.


#15

I just wanted to post a followup on Markus suggestion and I like to thank him.
Worked nicely!

But now I discovered the quality seems to be not as good as it used to be.
I will put this into another topic.
Over the 5+ years I have been using the tools from PVR, I noticed very often changes, why can’t it stay concistant. If you want to “play” make it a new option, don’t break old stuff please.


#16

I’ve chased up the TexTool lead. A fix for the issue has been back-ported to our upcoming release (due mid-March).

[blockquote]Over the 5+ years I have been using the tools from PVR, I noticed very often changes, why can’t it stay concistant. If you want to “play” make it a new option, don’t break old stuff please.[/blockquote]
The compressor does go through regression testing before each release, but it’s possible regressions will have occurred if we don’t have suitable tests in place to catch them. If you can explain the issues and share images to reproduce them I’ll discuss with the compressor team. Images can be shared privately by attaching them to a support portal ticket.


#17

Joe, I did as you suggested and wrote a support ticket.


#18

Everytime I want to compile an app on vs 2015 - it crashes. Even if I want to compile the main function or write something to it, there appears a window, which says.


#19

[quote quote=52152]Hi Pierre,

Thanks for reporting the issue. I’ve filed it as BRN58175 in our tracker. The PVRTexTool lead is now investigating.

[/quote]

BTW: There already exists a bug report from May 2015 for the very same issue:
https://pvrsupport.imgtec.com/feedback/view/82-pvrtextool-dll-cannot-be-used-safely-with-overloaded-new-delete

The comments say that Joe Davis also created an internal bug tracker entry back then. So maybe the TexLib lead should start taking those bug reports seriously without being bugged by Joe.