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.
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.
But: The transcode also decodes PVR, is there a performance or quality difference if I use the decoder function instead (from Utility`)?
[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.
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.
[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:
[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.
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)
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.
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.
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.
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]
support portal ticketThe 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 .
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.
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.
