Access violation from IPP Thread - Kindly Help(Urgent!!!!!)

[Cinu_Ts]

• We had written a dynamically linked library (DLL) for JPG encoding using Intel IPP libraries(IPP V 7.0 - ippj-7.0.dll).
• We made use of the classes in UIC sample code (UIC JPEGEncoder) for JPG encoding.
• In our scenario we had used the thread count for IPP and openMP as default (Which will be equals to the number of processors).
• An access violation has occurred in the application which loaded the JPEG encode library.
• On analyzing the crash dump generated, we came to know that the exception has occurred from the exit of a thread.
•  The call stack for the exception caused thread is shown below.

 1ac3fa94 77af7f02 kernel32!UnhandledExceptionFilter+0x127

1ac3fa9c 77a9e324 ntdll!__RtlUserThreadStart+0x62

1ac3fab0 77a9e1b4 ntdll!_EH4_CallFilterFunc+0x12

1ac3fad8 77ac7199 ntdll!_except_handler4+0x8e

1ac3fafc 77ac716b ntdll!ExecuteHandler2+0x26

1ac3fb20 77a9f98f ntdll!ExecuteHandler+0x24

1ac3fbac 77ac6ff7 ntdll!RtlDispatchException+0x127

1ac3fbac 05ff4513 ntdll!KiUserExceptionDispatcher+0xf

WARNING: Stack unwind information not available. Following frames may be wrong.

1ac3fedc 77aaf684 ippj_7_0!ippiEncodeHuffmanRawTableInit_JPEG_8u+0x11523

1ac3ff74 77aaf632 ntdll!LdrShutdownThread+0x35

1ac3ff84 76f0ed73 ntdll!RtlExitUserThread+0x2a

1ac3ff94 77ae377b kernel32!BaseThreadInitThunk+0x15

1ac3ffd4 77ae374e ntdll!__RtlUserThreadStart+0x70

1ac3ffec 00000000 ntdll!_RtlUserThreadStart+0x1b

• This library is dynamically loaded in our application (Using LoadLibrary API) and will be unloaded after use.
• When LoadLibrary API of JPEG encode library is called, 4 threads (2 IPP and 2 OpenMP) are spawned and if FreeLibrary is called, these threads are exited.
• But in issue occurred scenario, FreeLibary is not invoked (Threads are still alive). That is exception is thrown during the normal encoding operation.
• We assume that the exception has occurred from one of IPP spawned thread, since the function ippj_7_0!ippiEncodeHuffmanRawTableInit_JPEG_8u( as shown in the above call stack ) had called from this thread.
• We also ensured that the function ippiEncodeHuffmanRawTableInit_JPEG_8u is not get invoked during the normal execution flow for JPEG encoding from our JPEG encode library.

 So could you please let us know the scenario in which the function ippiEncodeHuffmanRawTableInit_JPEG_8u will be invoked?  And also please inform the possible causes of such a crash on IPP thread exit.

[Sergey_K_Intel]

Hi,

First of all, if I did external threading I would disable IPP's internal threading completely by using of static single-thread libraries or by setting ippSetNumThreads(1). Otherwise, internal and external threads are messed. From the stack info it seems like ippiEncodeHuffmanRawTableInit_JPEG_8u is called from thread shutdown. It mustn't be true. May it happen that some exception occurs in Huffman? DId you test your application in single-thread mode (i.e. calling as usual function)?

Regards,
Sergey 

[SergeyKostrov]

The ippiEncodeHuffmanRawTableInit_JPEG_8u function is invoked with 3 parameters and verify that memory for these buffers is Not corrupted. ... // Parameters: // pStatistics - pointer to array of 256 int, // with the one entry for each of possible huffman symbol. // pListBits - pointer to array of 16 bytes. // pListVals - pointer to array of 256 bytes. ...

[Sergey_K_Intel]

Agree with Sergey.

For external threading it is very important to know every time what memory you work with.

Is it thread-local? Is it shared? How it is guarded if shared?

Regards,
Sergey 

[SergeyKostrov]

>>...The ippiEncodeHuffmanRawTableInit_JPEG_8u function is invoked with 3 parameters and verify that >>memory for these buffers is Not corrupted... It could be done as follows: In case of a Windows platform and Visual Studio IDE allocate the memory for these three buffers using malloc_dbg CRT-function ( in Debug configuration ). If the memory is corrupted after the processing an error message will be displayed. Microsoft's memory leaks and buffer overflow detection subsystem is designed for such verifications.

[Cinu_Ts]

Our Applications is calling encoding from a single thread. So only one encoding will happen at a time. So we hope there isn’t having any problem in using multiple threads in IPP. Also we are not invoking ippiEncodeHuffmanRawTableInit_JPEG_8u function from our Dll. So the memory corruption possibilities are less. We don't know how this function call stack was come in issue thread. Also this issue is not reproducible

[Cinu_Ts]

Thank you for your replies.

Our Applications is calling encoding from a single thread. So only one encoding will happen at a time. So we hope there isn’t having any problem in using multiple threads in IPP. Also we are not invoking ippiEncodeHuffmanRawTableInit_JPEG_8u function from our Dll. So the memory corruption possibilities are less. We don't know how this function call stack was come in issue thread. Also this issue is not reproducible

[SergeyKostrov]

>>...And also please inform the possible causes of such a crash on IPP thread exit... Did you try to create a test case? If your test environment is Non-Deterministic ( it means every time a different input is used ) than it is very hard to reproduce the problem. Even if there was one crash something was wrong and without additional technical details it is impossible to "pin-point" the problem.