[FFmpeg-devel] FW: yuv420p_to_rgb24 core dump

[Stevens, Andrew J PNNL]

>On Fri, Sep 17, 2010 at 6:01 PM, Stevens, Andrew J (PNNL)
>><Andrew.Stevens at pnl.gov> wrote:
>>>On Fri, Sep 17, 2010 at 3:07 PM, Stevens, Andrew J (PNNL)
>>><Andrew.Stevens at pnl.gov> wrote:
>>>>> 0x0000000000899cc8 in yuv420_rgb24_MMX2
>>>[..]
>>>> (gdb) disass $pc-30 $pc+30
>>>> Dump of assembler code from 0x899efa to 0x899f36:
>>>
>>>No, we should see 899cc8-30 to 899cc8+30. Or did it now crash in a
>>>different place? Also, what does info all-registers say?
>>
>> Yes, but I don't know why.
>
>This suggests memory corruption. I'd suggest to run it under valgrind,
>and copy/paste the valgrind output here. That'll (hopefully) tell us
>the true reason that you're seeing crashes...


==28025== Memcheck, a memory error detector
==28025== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==28025== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==28025== Command: foo --leak-check=full -v
==28025==
==28025== Invalid read of size 8
==28025==    at 0x853688: yuv420_rgb24_MMX2 (yuv2rgb_template2.c:327)
==28025==    by 0x8324A6: sws_scale (swscale.c:1931)
==28025==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==28025==
==28025==
==28025== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==28025==  Access not within mapped region at address 0x0
==28025==    at 0x853688: yuv420_rgb24_MMX2 (yuv2rgb_template2.c:327)
==28025==    by 0x8324A6: sws_scale (swscale.c:1931)
==28025==  If you believe this happened as a result of a stack
==28025==  overflow in your program's main thread (unlikely but
==28025==  possible), you can try to increase the size of the
==28025==  main thread stack using the --main-stacksize= flag.
==28025==  The main thread stack size used in this run was 10485760.
==28025==
==28025== HEAP SUMMARY:
==28025==     in use at exit: 11,547,514 bytes in 98 blocks
==28025==   total heap usage: 421 allocs, 323 frees, 21,161,304 bytes allocated
==28025==
==28025== LEAK SUMMARY:
==28025==    definitely lost: 0 bytes in 0 blocks
==28025==    indirectly lost: 0 bytes in 0 blocks
==28025==      possibly lost: 180 bytes in 5 blocks
==28025==    still reachable: 11,547,334 bytes in 93 blocks
==28025==         suppressed: 0 bytes in 0 blocks
==28025== Rerun with --leak-check=full to see details of leaked memory
==28025==
==28025== For counts of detected and suppressed errors, rerun with: -v
==28025== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Segmentation fault

Anything new on this?

Thanks,
Andrew Stevens