topic Re: ippsFFTFwd access violation in Intel® Integrated Performance Primitives

ippsFFTFwd access violation

Intel_C_Intel — Fri, 03 Nov 2006 07:26:42 GMT

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?

Re: ippsFFTFwd access violation

Intel_C_Intel — Fri, 03 Nov 2006 07:54:07 GMT

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

Re: ippsFFTFwd access violation

Vladimir_Dudnik — Mon, 06 Nov 2006 21:51:32 GMT

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

Re: ippsFFTFwd access violation

Intel_C_Intel — Tue, 07 Nov 2006 02:58:09 GMT

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

Re: ippsFFTFwd access violation

Intel_C_Intel — Tue, 07 Nov 2006 07:06:09 GMT

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

Re: ippsFFTFwd access violation

Intel_C_Intel — Wed, 08 Nov 2006 07:54:18 GMT

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

Re: ippsFFTFwd access violation

Vladimir_Dudnik — Fri, 17 Nov 2006 01:26:01 GMT

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