sample umc_video_enc_con with h264 crashes with double free

[johno74]

Hi,

I've installed IPP for a trial period, the version is ..

Package ID: l_ipp-samples_p_7.0.3.040
Package Contents: Intel IPP Samples for Linux*

I don't have any other Intel tools or libraries installed. I'm building with gcc 4.3.2

When I run ..

./umc_video_enc_con h264 -i ~/vts_640_480.yuv -o ./1.h264 -w 640 -h 480 -b 100000

.. I succesfully encode a h264 frame, but it segfaults with a back trace ..

Summary:
Num frames encoded = 1
Encoding Time = 0.04 sec, 23.68 fps
Overall Time = 0.04 sec, 22.77 fps
Average CPU usage = 0.00%
Encoded Size = 31245 bytes
Compression Ratio = 14.75
EncodedSize/ExpectedSize = 74.99
*** glibc detected *** ./umc_video_enc_con: double free or corruption (!prev): 0x09fcf5f0 ***



In the Mafile in ipp-samples/audio-video-codecs I added -ggdb to CFLAGS, ran the above line again with coredumps enabled and my stack trace is

#0 0x0063e416 in __kernel_vsyscall ()
#1 0x00249460 in raise () from /lib/libc.so.6
#2 0x0024ae28 in abort () from /lib/libc.so.6
#3 0x00286fed in __libc_message () from /lib/libc.so.6
#4 0x0028d3a4 in malloc_printerr () from /lib/libc.so.6
#5 0x0028f356 in free () from /lib/libc.so.6
#6 0x00f6aa85 in ippFree () from /opt/intel/composerxe/ipp/lib/ia32/libippcore.so.7.0
#7 0x08d155f0 in ?? ()
#8 0x00000002 in ?? ()
#9 0x081381c3 in UMC_H264_ENCODER::H264CoreEncoder_Close_8u16s (state=0x0) at ./include/umc_h264_gen_enc_tmpl.cpp.h:2086

I see in the bug fixes (http://software.intel.com/en-us/articles/intel-ipp-70-library-bug-fixes/) that a similar issue was recently fixed ..

IPP v7.0 update 2 (20 Jan 2011) .. "Fixed crash with double memory free in h264 encoder when calling core encode destructor after Close() method."

.. however I'd assume that the version of the samples I have (ipp-samples_p_7.0.3.040) would contain this update 2 fix.

In case this is related, I didn't seem to get IPPROOT setup correctly. Each time I ran the app it ended up not finding a library in another directory path, so to get the binary running at all I set LD_LIBRARY_PATH to

/opt/intel/composerxe/ipp/lib/ia32/:/opt/intel/composerxe-2011.3.174/compiler/lib/ia32/

I'd appreciate any help or pointers.

John

[johno74]

by the way , the line which appears to be causing the core is (./include/umc_h264_gen_enc_tmpl.cpp.h:2086
)


#ifdef SLICE_THREADING_LOAD_BALANCING
// Load balancing for slice level multithreading
H264_Free(core_enc->m_B_ticks_per_macroblock); /********* line shown in the stack trace
H264_Free(core_enc->m_P_ticks_per_macroblock);
#endif // SLICE_THREADING_LOAD_BALANCING
return UMC_OK;


which belongs to the samples .. l_ipp-samples_p_7.0.3.040

[Ying_H_Intel]

Hi John

Thanks for the report.We are looking at thisissue, and will provide you an update. Just confirm with you, that the input YUV contains only1 frame, right?

Regards,
Ying

[Ying_H_Intel · Accepted solution]

Hi John,

We can reproduce the problem. Will escalte to the developer for further investigation.

For simpletemp workaround, you may modify the Makefile, comment the second CFLAGS += -fopenmp

ifeq ("$(OPENMP_SUPPORT)","")
CFLAGS += -openmp
else
ifeq ($(OPENMP_SUPPORT),YES)
# CFLAGS += -fopenmp
endif
endif

rebuild, thenitshould work.

Thanks
Ying

[johno74]

Hi Ying,

>>Just confirm with you, that the input YUV contains only1 frame, right?

Yes, that's correct.

I have tried the workaround you described and I can now encode without any problem.

Many thanks,
John

[johno74]

Hi, what are the consequences of disabling that build option ?

John

[Ying_H_Intel]

Hi John,

It should be not direct result. I doubt there is conflict when use Intel OpenMP and GNU openMP. So disable it.Do you have chance to try intel C++ compiler to build the sample?, it seems works fine with the 1 frame encoding.


Best Regards,
Ying

[johno74]

Hi Ying,

Thanks for the reply. I haven't had the opportunity to try building using the Intel C++ yet. Hopefully I'll get the time to try this in the near future.

John

[Ying_H_Intel]

Hi John,

Just glad to notify you that IPPdeveloperhave formally fixed the problem in IPP 7.0.5.
The release is available for download in Intel registraction center.
And the sample code are Code Samples for the Intel Integrated Performance Primitives (Intel IPP) Library 7.0*.

You are welcomed to try it.

Thanks,
Ying