Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.

[FIXED in v7.1] Delete JPEG decoder crashes in Debug mode

Sean_V_2
Beginner
705 Views

Hello there,

We've been using Intel IPP since version 6.0 and since then we've been noticing problems with UIC libs. We use all the UIC codecs in our application and we found out that deleting the jpeg object in Debug mode causes the application to crash. In Release mode it works with no problems. We initialize  UIC::BaseImageDecoder* dec = NULL; and then depending on the file type we construct appropriate decoder with dec = new JPEGDecoder() (or others).

After we finish working with it, we tried calling dec->Close() and then deleting dec, but it crashed with no stack trace on delete dec. Any help is welcome.

This is all happening with dynamically linked UIC libs version 7.0.7.

Thanks a lot.

0 Kudos
11 Replies
SergeyKostrov
Valued Contributor II
705 Views
Let's consider a pseudo-code: ... class JPEGDecoder { public: JPEGDecoder() { ... }; ~JPEGDecoder() <= set a break point here { ... }; ... }; ... void main( void ) { JPEGDecoder *dec = new JPEGDecoder(); ... if( dec != NULL ) { dec->Close(); delete dec; // Here it crashes, right? } ... } When you're debugging try to step into delete C++ operator or set a break point in JPEGDecoder::~JPEGDecoder destructor in order to see what is going on there. I could assume that some resource is de-allocated twice.
0 Kudos
manca1
Beginner
705 Views

Hello,

I can't stop in source of JPEGDecoder because I am using prebuilt libraries and UIC dlls. Can you try to reproduce the bug yourself?

Thanks.

0 Kudos
manca1
Beginner
705 Views

Anyone?

0 Kudos
Sergey_K_Intel
Employee
705 Views

Hi,

Do not use Close() here. ~JPEGDecoder calls Close() itself and there is double "delete m_jpeg".
This is fixed in 7.1.

Regards,
Sergey 

0 Kudos
SergeyKostrov
Valued Contributor II
705 Views
>>...Do not use Close() here. ~JPEGDecoder calls Close() itself and there is double "delete m_jpeg". This is fixed in 7.1. Thanks for the confirmation that some issues are fixed.
0 Kudos
manca1
Beginner
705 Views

Even without Close(), it still crashes.

0 Kudos
SergeyKostrov
Valued Contributor II
705 Views
>>...Even without Close(), it still crashes... Please take a look. This is your statement: >>...This is all happening with dynamically linked UIC libs version 7.0.7... This is Sergey Khlystov (Intel) statement: >>...This is fixed in 7.1... So, my question is did you upgrade the IPP library to version 7.1?
0 Kudos
manca1
Beginner
705 Views

This is what you said:

"Do not use Close() here. ~JPEGDecoder calls Close() itself and there is double "delete m_jpeg". 
This is fixed in 7.1."

I understood that Close() calls delete m_jpeg and then since destructor calls Close() again it deletes already deleted pointer. Now, I tried removing Close() and leaving destructor calls it and the application still crashes. Did you mean to say that destructor calls delete m_jpeg as well as Close(). Meaning you had a big bug in your code. I'll try 7.1 and see if it works.

Thanks.

0 Kudos
SergeyKostrov
Valued Contributor II
705 Views
>>... I'll try 7.1 and see if it works. Please try it. Here is a generic explanation of why it happens: [ A version with a Bug ] ... JPEGDecoder::~JPEGDecoder() { Close(); }; JPEGDecoder::Close() { DeallocateResource( pSomePointer ); }; ... [ A Correct version ] ... JPEGDecoder::~JPEGDecoder() { Close(); }; JPEGDecoder::Close() { if( pSomePointer != NULL ) { DeallocateResource( m_pSomePointer ); m_pSomePointer = NULL; } }; ... Note: In that case a "double" deallocation of some resource in m_pSomePointer simply impossible and such errors / bugs are very common.
0 Kudos
manca1
Beginner
705 Views

Works with IPP 7.1. Thank you.

0 Kudos
SergeyKostrov
Valued Contributor II
705 Views
>>Works with IPP 7.1. Thank you. Thanks for the confirmation. You could also chage the title of the thread to [ FIXED in v7.1 ] Delete JPEG decoder crashes in Debug mode.
0 Kudos
Reply