Access Violation Issue in ippiCrossCorrValid_NormLevel_32f_C1R

sundar_r_ — Mon, 26 Sep 2016 14:49:24 GMT

Hi, We are using "ippiCrossCorrValid_NormLevel_32f_C1R" to find out cross correlation in our application running in Windows 7 64bit machine. The application is getting crashed after calling function "ippiCrossCorrValid_NormLevel_32f_C1R". We have did initial analysis of the crash dump and below are the details. The IPP version we are using is 6.1. We would need help to proceed further on narrowing down the issue. And we also want to know if it is a existing issue with IPPAPI? Windbg analysis ----------------------- 0:081> .ecxr rax=0000000028b44700 rbx=000000000000000c rcx=0000000000000032 rdx=0000000031e03880 rsi=0000000000000001 rdi=000000000000000b rip=0000000026f91bdc rsp=0000000046604630 rbp=0000000028b19880 r8=0000000000000032 r9=0000000000000008 r10=0000000000000000 r11=0000000000000206 r12=0000000000000003 r13=0000000031e03880 r14=0000000000000000 r15=0000000031e03880 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010204 libiomp5md!_kmp_launch_worker+0x41c: 00000000`26f91bdc 458b8ee8090000 mov r9d,dword ptr [r14+9E8h] ds:00000000`000009e8=???????? 0:081> .exr -1 ExceptionAddress: 0000000026f91bdc (libiomp5md!_kmp_launch_worker+0x000000000000041c) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 0000000000000000 Parameter[1]: 00000000000009e8 Attempt to read from address 00000000000009e8 0:081> ub . L10 libiomp5md!_kmp_launch_worker+0x3eb: 00000000`26f91bab c3 ret 00000000`26f91bac 8b0d0a690400 mov ecx,dword ptr [libiomp5md!_kmp_debugging+0x26b4 (00000000`26fd84bc)] 00000000`26f91bb2 ff1548b50200 call qword ptr [libiomp5md!_kmp_release_bootstrap_lock+0x28314 (00000000`26fbd100)] 00000000`26f91bb8 83c0ff add eax,0FFFFFFFFh 00000000`26f91bbb 4883c428 add rsp,28h 00000000`26f91bbf c3 ret 00000000`26f91bc0 4157 push r15 00000000`26f91bc2 4156 push r14 00000000`26f91bc4 56 push rsi 00000000`26f91bc5 55 push rbp 00000000`26f91bc6 53 push rbx 00000000`26f91bc7 4883ec20 sub rsp,20h 00000000`26f91bcb 4989d7 mov r15,rdx 00000000`26f91bce 488b05ab340400 mov rax,qword ptr [libiomp5md!_kmp_ompd_minor_version+0x4758 (00000000`26fd5080)] 00000000`26f91bd5 4c63c1 movsxd r8,ecx 00000000`26f91bd8 4e8b34c0 mov r14,qword ptr [rax+r8*8] 0:081> u libiomp5md!_kmp_launch_worker+0x41c: 00000000`26f91bdc 458b8ee8090000 mov r9d,dword ptr [r14+9E8h] 00000000`26f91be3 4585c9 test r9d,r9d 00000000`26f91be6 746d je libiomp5md!_kmp_launch_worker+0x495 (00000000`26f91c55) 00000000`26f91be8 498db6c0090000 lea rsi,[r14+9C0h] 00000000`26f91bef 498dae80090000 lea rbp,[r14+980h] 00000000`26f91bf6 498d9e88090000 lea rbx,[r14+988h] 00000000`26f91bfd 4889f1 mov rcx,rsi 00000000`26f91c00 ff150ab50200 call qword ptr [libiomp5md!_kmp_release_bootstrap_lock+0x28324 (00000000`26fbd110)] (Below are the details of the stack from which function "ippiCrossCorrValid_NormLevel_32f_C1R" is invoked from our application) 0:097> !dumpstack OS Thread Id: 0x1dc0 (97) Current frame: ippiy8_6_1!ippiZigzagInv8x8_16s_C1+0x939d1 Child-SP RetAddr Caller, Callee 0000000031a3d180 000000002957dbdb ippiy8_6_1!ippiCopy_32f_C1R+0x3b, calling ippiy8_6_1!ippiZigzagInv8x8_16s_C1+0x9380c 0000000031a3d1c0 00000000298fd4bc ippiy8_6_1!ippiZigzagInv8x8_16s_C1+0x79be8, calling ippiy8_6_1!ippiCopy_32f_C1R 0000000031a3d1e0 0000000025444085 ippcoreem64t_6_1!ippMalloc+0x15, calling ippcoreem64t_6_1!ippGetLibVersion+0x54 0000000031a3d240 00000000295fa51c ippiy8_6_1!ippiCrossCorrValid_NormLevel_32f_C1R+0x60c, calling ippiy8_6_1!ippiZigzagInv8x8_16s_C1+0x79b80 0000000031a3d2b0 00000000770affa5 ntdll!RtlAllocateHeap+0x4e5, calling ntdll!RtlLeaveCriticalSection 0000000031a3d4f0 0000000026f7117c libiomp5md!_kmp_invoke_microtask+0x8c 0000000031a3d500 000007fefd30133c KERNELBASE!SetEvent+0xc, calling ntdll!NtSetEvent 0000000031a3d510 0000000026f98fa7 libiomp5md!_kmp_release_bootstrap_lock+0x41bb, calling ntdll!RtlAllocateHeap 0000000031a3d640 0000000026f78a97 libiomp5md!_kmpc_invoke_task_func+0x83, calling libiomp5md!_kmp_invoke_microtask 0000000031a3d680 0000000026f7a39c libiomp5md!_kmp_fork_call+0x4ac 0000000031a3d740 0000000026f81455 libiomp5md!_kmpc_fork_call+0x81, calling libiomp5md!_kmp_fork_call 0000000031a3d750 000000002966febb ippiy8_6_1!ippiFFTInitAlloc_R_32f+0x21b, calling ippiy8_6_1!ippiZigzagInv8x8_16s_C1+0x4f5664 0000000031a3d760 0000000026f7589d libiomp5md!kmp_set_defaults+0x3605, calling libiomp5md!_kmp_release_bootstrap_lock 0000000031a3d790 0000000026f8147d libiomp5md!_kmpc_push_num_threads+0x11, calling libiomp5md!_kmp_wait_sleep+0x14ec 0000000031a3d7c0 00000000295fad78 ippiy8_6_1!ippiCrossCorrValid_NormLevel_32f_C1R+0xe68, calling ippiy8_6_1!ippiZigzagInv8x8_16s_C1+0x501316 0000000031a3d970 0000000074518d17 msvcr100!malloc+0x5b, calling ntdll!RtlAllocateHeap 0000000031a3da10 0000000076f61a7a kernel32!HeapFree+0xa, calling ntdll!RtlFreeHeap 0000000031a3da70 000007fedd8fed67 ApplicationAlgorithm::CalcAlignOffsets+0x737, calling ippiem64t_6_1!ippiCrossCorrValid_NormLevel_32f_C1R More details on our application: Our application is a .Net application which uses our internal c++ algorithm library(say 'ApplicationAlgorithm'), which further uses ipp call. Unfortunately we don't have a prototype that repro this crash, as the crash is intermittent and not happens always. Please let us know any more details that I can provide. Thanks in Advance!

Hi Sandar,

Shaojuan_Z_Intel — Tue, 27 Sep 2016 00:06:16 GMT

Hi Sandar,

I noticed your IPP version is very old. If possible, could you upgrade to the latest IPP 2017 that just released this month and see if the problem still exist? You can download the community license version that is free here https://software.intel.com/en-us/articles/free-ipsxe-tools-and-libraries. Thanks!

Thanks Shaojuan for the quick

sundar_r_ — Tue, 27 Sep 2016 08:34:41 GMT

Thanks Shaojuan for the quick reply! Agree with you completely. In our application we have heavily used ipp 6.1 in several places. Moving to latest IPP would require us to do a complete regression & baseline testing. If we get a confirmation\rootcause that the issue is because of old ipp libraries, then I would take it up further with our team on moving to latest IPP. Things of concern 1. Will moving to latest IPP cause baseline shifts in the results from IPPAPI calls? 2. Or else can I use latest IPP only to replace 'ippiCrossCorrValid_NormLevel_32f_C1R' functions and the rest will continue to use old IPP. But all of the IPPAPI calls we are using are in a single project. Will it not give a conflict as our project is linked to ipp libraries? or how to handle it separately. Please let know your suggestions. Thanks, Sundar

Hi Sundar,

Shaojuan_Z_Intel — Wed, 28 Sep 2016 00:27:55 GMT

Hi Sundar,

ippiCrossCorrValid_NormLevel_32f_C1R has been deprecated from later releases, you may need to use a replacing function in the newer version. There could be changes in IPP APIs and performance from different versions. For your concern 2, you may check this link https://software.intel.com/en-us/forums/intel-integrated-performance-primitives/topic/392804 and see if it feasible for your application. Without a reproducible code, it is hard to pinpoint the issue especially when it intermittent. Thanks!

Thanks Shaojuan for answering

sundar_r_ — Mon, 03 Oct 2016 10:54:25 GMT

Thanks Shaojuan for answering all my queries!

topic Hi Sandar, in Intel® Integrated Performance Primitives

Access Violation Issue in ippiCrossCorrValid_NormLevel_32f_C1R

Hi Sandar,

Thanks Shaojuan for the quick

Hi Sundar,

Thanks Shaojuan for answering