ippsFFTFwd access violation

[Intel_C_Intel]

Getting the following access violation when executing the ippsFFTFwd_RToPack_64f_I command:

0xC0000005: Access violation writing location 0x00000000.

Here's the relevant snippits from my code:

 IppsFFTSpec_R_64f * mIppFFTSpecP;
 UInt8 * mIppWorkBufferP;
 double *fftBuffer1 = new double[4096];
    int fftOrder = 13; 
 result = ippSetNumThreads(1);  // Multithreading needs to be turned off for my purposes
 result = ippsFFTInitAlloc_R_64f(
       &mIppFFTSpecP,    
       fftOrder,
       IPP_FFT_DIV_FWD_BY_N, 
       ippAlgHintNone);  
 int ippFftWorkBufferSize = 0;
 result = ippsFFTGetBufSize_R_64f(
      mIppFFTSpecP, 
      &ippFftWorkBufferSize);
 mIppWorkBufferP = new UInt8[ippFftWorkBufferSize];
 result = ippsFFTFwd_RToPack_64f_I(
       fftBuffer1,
       mIppFFTSpecP,     
       mIppWorkBufferP);  

Any suggestions?

[Intel_C_Intel]

I've found another problem in this code:

When I call ippsFFTGetBufSize, the value of ippFftWorkBufferSize remains 0. What would cause an invalid value to be returned?

result = ippsFFTGetBufSize_R_64f(
mIppFFTSpecP,
&ippFftWorkBufferSize);

[Vladimir_Dudnik]

Hello,

Zero size is valid for that function. Please pay attention that you trying to call FFT for order 13 but providing only 4096 elements buffer.

Regards,
Vladimir

[Intel_C_Intel]

Thank you for your response, Vladimir -

I had a typo in my previous post. I am indeed using an order of 12.

I have tested the code with a statically-linked version of IPP 4.0, and everything works fine without any exception errors at all. (Replacing the in-place FFT call with the IPP 4.0 equivalent, of course).

Is there any possible reason that, in a large multi-threaded application, the dynamically-linked IPP 5.1 code will generate exceptions when statically-linked IPP 4.0 code will succeed? I have tried disabling IPP multithreading by setting ippSetNumThreads(1), like the Tips documentation suggests, but it does not help.

Thanks,
Ryan

[Intel_C_Intel]

Some more info on this problem:

I am getting access violations in both the FFTFwd and FFTInv routines. Here is some debug dump info:

FFTFwd:

-------

First-chance exception at 0x7c9111de in ProTools.exe: 0xC0000005: Access violation reading location 0x3c7068da.

(Address 0x7c9111de is in ntdll.dll)

EAX = 3C7068DA EBX = 17E20000 ECX = 17E23D78 EDX = 17E20378 ESI = 17E23D70 EDI = 9A2B23D9 EIP = 7C9111DE ESP = 1C79EBFC EBP = 1C79EE1C EFL = 00010202 

..

7C9111C4 sub esi,8 

7C9111C7 mov dword ptr [ebp-38h],esi 

7C9111CA lea ecx,[esi+8] 

7C9111CD mov edi,dword ptr [ecx] 

7C9111CF mov dword ptr [ebp-0F4h],edi 

7C9111D5 mov eax,dword ptr [esi+0Ch] 

7C9111D8 mov dword ptr [ebp-98h],eax 

7C9111DE mov edx,dword ptr [eax]  <---- Breaks here

7C9111E0 cmp edx,dword ptr [edi+4] 

..

FFTInv:

-------

First-chance exception at 0x17d39f0b in ProTools.exe: 0xC0000005: Access violation reading location 0x00000000.

EAX = 00000800 EBX = 192723E0 ECX = 192763E0 EDX = 00000000 ESI = 192723E0 EDI = 1927A3E0 EIP = 17D39F0B ESP = 1C79EE58 EBP = 1927A3E0 EFL = 00000206 

(Address 0x17d39f0b is in ippsv8-5.1.dll)

17D39EE6 movsd xmm4,mmword ptr [edi-8] 

17D39EEB movsd xmm7,mmword ptr [edi-18h] 

17D39EF0 movlhps xmm4,xmm7 

17D39EF3 movapd xmm2,xmm0 

17D39EF7 subpd xmm0,xmm3 

17D39EFB addpd xmm2,xmm3 

17D39EFF movapd xmm5,xmm1 

17D39F03 addpd xmm5,xmm4 

17D39F07 subpd xmm1,xmm4 

17D39F0B movapd xmm6,xmmword ptr [edx]  <---- Breaks here

17D39F0F mulpd xmm6,xmm0 

17D39F13 movapd xmm7,xmmword ptr [edx+10h] 

17D39F18 mulpd xmm0,xmm7 

17D39F1C mulpd xmm7,xmm5 

[Intel_C_Intel]

OK, I found out the cause of this problem.

In the application that was using the IPP functions, we are also using a third-party library that contains IPP code. The IPP code linked in the 3rd-party library is an older version, which for some reason is confusing the IPPCore dispatcher. We're currently working on ways in which we can include both libraries without conflict.

-Ryan

[Vladimir_Dudnik]

Hi Ryan,

that's great you find solution!

By the way, could youshare the name of third party component which also use IPP?

Regards,
Vladimir