PVRTexLib Crash with Visual Studio 2015

This topic contains 18 replies, has 4 voices, and was last updated by  Markus Henschel 1 year, 7 months ago.

Viewing 15 posts - 1 through 15 (of 19 total)
  • Author
    Posts
  • #52120

    Pierre
    Member

    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:

    #include “PVRTexture.h” 
    using namespace pvrtexture; 
    
    int main[int argc, char *argv[]]
    {
      CPVRTextureHeader pvr_header;
    }
    

    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.

    #52152

    Joe Davis
    Member

    Hi Pierre,

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

    #52154

    Pierre
    Member

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

    #52199

    Joe Davis
    Member

    I am not sure if it is really a bug or if something on my side is wrong.

    From our initial analysis, we suspect this is a bug. The PVRTexTool lead is investigating now.

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

    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.

    #52200

    Pierre
    Member

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

    #52634

    Pierre
    Member

    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.

    #52641

    Joe Davis
    Member

    Can someone please look into this?

    I’ll discuss the issue with the TexTool lead.

    Any reason those were added?

    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:

      BRN58442: SDK Framework: Reduce PVRTDecompress.cpp header dependencies
    #52697

    Joe Davis
    Member

    Can someone please look into this?

    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.

    #52698

    Pierre
    Member

    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.

    #52843

    Pierre
    Member

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

    #52915

    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.

    #52917

    Pierre
    Member

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

    #52918

    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:

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

    This doesn’t crash for me.

    #52930

    Joe Davis
    Member

    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.

    #52933

    Pierre
    Member

    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.

Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic.