CPVRTextureHeader crash

This topic contains 8 replies, has 2 voices, and was last updated by  Deep 4 years, 7 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #31173

    Deep
    Member

    I’ve got some code to compress a texture that used to work, but when I upgraded to v3.0 of the Windows SDK it crashes. Ironically, the compression actually finishes successfully, but it crashes when the CPVRTextureHeader “header” goes out of scope. It appears to crash trying to delete the MetaDataBlock in the destructor.

    Below is the original code that worked in the previous version, and my attempt to port this to version 3. Oddly, both compile, compress successfully, and crash when the header goes out of scope. Can anyone point out what I’m doing wrong here?

    // version 2
    pvrtexture::CPVRTextureHeader header(pvrtexture::PVRStandard8PixelType.PixelTypeID, nHeightSrc, nWidthSrc );
    pvrtexture::CPVRTexture cTexture( header, pDataRGBA );
    pvrtexture::PixelType PVRTC4BPP( (dstFormat == FORMAT_PVR_RGBA) ? ePVRTPF_PVRTCI_4bpp_RGBA : ePVRTPF_PVRTCI_4bpp_RGB );
    bSuccess = Transcode( cTexture, PVRTC4BPP, ePVRTVarTypeUnsignedByteNorm, ePVRTCSpacelRGB );
    crt::memcpy( pDstData, cTexture.getDataPtr(), nDstSize );
    if ( kPixelTypeSrc != pixelTypeRGBA ) free( pDataRGBA );

    // version 3
    pvrtexture::CPVRTextureHeader header( (dstFormat == FORMAT_PVR_RGBA) ? ePVRTPF_PVRTCI_4bpp_RGBA : ePVRTPF_PVRTCI_4bpp_RGB,
    nHeightSrc, nWidthSrc );
    pvrtexture::CPVRTexture cTexture( header, pDataRGBA );
    bSuccess = Transcode( cTexture, (dstFormat == FORMAT_PVR_RGBA) ?
    pvrtexture::PixelType( ‘r’, ‘g’, ‘b’, ‘a’, 8, 8, 8, 8 ) :
    pvrtexture::PixelType( ‘r’, ‘g’, ‘b’, 0, 8, 8, 8, 0 ),
    ePVRTVarTypeUnsignedByteNorm, ePVRTCSpacelRGB );
    crt::memcpy( pDstData, cTexture.getDataPtr(), nDstSize );
    if ( kPixelTypeSrc != pixelTypeRGBA ) free( pDataRGBA );

    #36786

    Hi Deep,

    Is this definitely all the code you are using? There’s no reason that meta data should be generated at any point in either of these code snippets – so if it’s trying to delete a MetaDataBlock that’s a serious error, and leads me to believe that the header has been corrupted somehow.

    The most obvious thing I’m noticing that could potentially be a problem – you don’t specify how you get nDstSize – could you check the value of nDstSize against cTexture.getDataSize() immediately before the memcpy? If they differ that might point at a problem. I’d also suggest commenting out the memcpy and free operations to see if the crash still occurs.

    Thanks,
    Tobias

    #36787

    Deep
    Member

    Yes, this is all the code I’m using. In fact, I even commented out everything but the creation of the CPVRTextureHeader on the stack and it still crashes when it goes out of scope. The stack trace is shown below

    > msvcr90d.dll!operator delete(void * pUserData=0x030e2c80) Line 52 + 0x51 bytes C++
    msvcr90d.dll!operator delete[](void * p=0x030e2c80) Line 21 + 0x9 bytes C++
    mylibD.dll!MetaDataBlock::`vector deleting destructor'() + 0x3f bytes C++
    mylibD.dll!CPVRTArray::~CPVRTArray() Line 112 + 0x1f bytes C++
    mylibD.dll!CPVRTMap::~CPVRTMap() Line 51 + 0xf bytes C++
    mylibD.dll!`eh vector destructor iterator'(void * ptr=0x030e15e0, unsigned int size=36, int count=15, void (void *)* pDtor=0x008b623f) + 0x67 bytes C++
    mylibD.dll!CPVRTMap::`vector deleting destructor'() + 0x2b bytes C++
    mylibD.dll!CPVRTArray<CPVRTMap >::~CPVRTArray<CPVRTMap >() Line 112 + 0x1f bytes C++
    mylibD.dll!CPVRTMap<unsigned int,CPVRTMap >::~CPVRTMap<unsigned int,CPVRTMap >() Line 51 + 0xf bytes C++
    mylibD.dll!pvrtexture::CPVRTextureHeader::~CPVRTextureHeader() + 0x17 bytes C++
    mylibD.dll!TextureCompression::compress(vuImageBase * pDstImage=0x05c828e8, const vuImageBase * kpSrcImage=0x05c828b8, TextureCompression::Format dstFormat=FORMAT_PVR_RGB, int nLayer=0) Line 633 C++

    Note that if I create the header as a pointer, and don’t delete it, the code runs to completion. However, only the version 2 code above produces the correct visual result. Do you see anything wrong w/ my version 3 code, or is the version 2 code still valid to use w/ version 3?

    #36788

    Your version 2 code is definitely valid, there’s no good reason it shouldn’t work. Could you give me some information about the setup you’re using?

    – Which version of the library are you using (see PVRTextureVersion.h)?
    – Which version of the SDK are you using (There will be a changelist number mentioned in our GUI utilities when viewing the about box)?
    – I assume you’re using Windows, and the static PVRTexLib library?
    – Which version of Visual Studio are you using?
    – Are you linking against the Tools libraries as well as PVRTexLib?

    Regards,
    Tobias

    #36789

    Deep
    Member

    – 4.3
    – the changelist number is 3.0@2230060
    – I’m on Windows 7 and I’m linking against PVRTexLib.lib (dynamic)
    – Visual Studio 2008
    – I link against PVRTexLib only, the only other libs I link against are libGLESv2.lib and libEGL.lib

    #36790

    Hi Deep,

    Thanks very much for the info – the problem is that you’re using VS2008. We upgraded to VS2010 in the 3.0 release, and visual studio doesn’t do well when versions are crossed like that. It results in a huge number of weird errors ranging from simple uninitialised values to crashes like you’ve described above.

    The best thing to do is to upgrade to either VS2010, or upgrade to VS2012 and use the 2010 toolchain.

    Sorry I can’t be of more help!

    Thanks,
    Tobias

    #36791

    Deep
    Member

    I upgraded to VS2010 and I get the same result.

    #36792

    Hi Deep,

    It occurs to me there is another thing that would cause the issue – have you defined “_WINDLL_IMPORT”, and are you including “PVRTexturedefines.h” before any other PVRTexLib headers?

    Thanks,
    Tobias

    #36793

    Deep
    Member

    No, I did not have that defined. Defining _WINDLL_IMPORT stopped it from crashing. Thanks.

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