Re: Request help debugging octave-video in mxe-octave

[John Swensen]

> On Jan 1, 2016, at 10:58 AM, Andreas Weber <address@hidden> wrote:
> 
> Dear maintainers,
> 
> I need some help debugging octave-video with ffmpeg in mxe-octave.
> Sometimes I get a strange segmentation fault in the AVHandler destructor.
> 
> What I've done so far:
> Crosscompile mxe-octave on Debian Jessie with
> $ ./configure --disable-strip-dist-files --enable-devel-tools 
> --enable-binary-packages
> $ make gdb ffmpeg zip-dist
> 
> In Windows7, extract zip, and grab code from 
> http://sourceforge.net/p/octave/video/ci/default/tree/
> run octave in CLI mode, getpid, attach gdb.
> 
> Back in Octave:
> >> cd octave/video/src
> >> test avifile
> 
> This sometimes works (PASS 1/1) and sometimes fails at different places:
> 
> ----------------------------------------------------
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 2648.0x7f4]
> 0x7795e3c6 in ntdll!RtlInitUnicodeString () from C:\Windows\SysWOW64\ntdll.dll
> (gdb)
> Continuing.
> 
> --------------------------------------------------
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 3212.0xe9c]
> 0x77963aa8 in ntdll!RtlQueryPerformanceCounter ()
>   from C:\Windows\SysWOW64\ntdll.dll
> (gdb) bt
> #0  0x77963aa8 in ntdll!RtlQueryPerformanceCounter ()
>   from C:\Windows\SysWOW64\ntdll.dll
> #1  0x77962c7a in ntdll!RtlQueryPerformanceCounter ()
>   from C:\Windows\SysWOW64\ntdll.dll
> #2  0x77962b65 in ntdll!RtlQueryPerformanceCounter ()
>   from C:\Windows\SysWOW64\ntdll.dll
> #3  0x76b698cd in msvcrt!free () from C:\Windows\syswow64\msvcrt.dll
> #4  0x17aa0000 in ?? ()
> #5  0x1c0159fe in avpriv_mpa_decode_header ()
>   from C:\octave-dbg\octave-4.0.0\bin\avcodec-56.dll
> #6  0x1c3bcce9 in avcodec-56!av_dct_end ()
>   from C:\octave-dbg\octave-4.0.0\bin\avcodec-56.dll
> #7  0x1c3ce86e in avcodec_close ()
>   from C:\octave-dbg\octave-4.0.0\bin\avcodec-56.dll
> #8  0x6660167c in AVHandler::~AVHandler (this=0x1bacd708,
>    __in_chrg=<optimized out>) at AVHandler.cc:83
> #9  0x6660384a in Avifile::~Avifile (this=0x1bc20c90,
> 
> ---------------------------------------------------------
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 3184.0xe48]
> 0x77962e33 in ntdll!RtlQueryPerformanceCounter ()
>   from C:\Windows\SysWOW64\ntdll.dll
> (gdb) bt
> #0  0x77962e33 in ntdll!RtlQueryPerformanceCounter ()
>   from C:\Windows\SysWOW64\ntdll.dll
> #1  0x77962b65 in ntdll!RtlQueryPerformanceCounter ()
>   from C:\Windows\SysWOW64\ntdll.dll
> #2  0x76b698cd in msvcrt!free () from C:\Windows\syswow64\msvcrt.dll
> #3  0x17a70000 in ?? ()
> #4  0x0128b8bc in ~ArrayRep (this=0x1bbfaa70, __in_chrg=<optimized out>)
>    at 
> /home/andy/src/mxe-octave/tmp-stable-octave/octave-4.0.0/liboctave/array/
> Array.h:89
> #5  Array<double>::~Array (this=0x0, __in_chrg=<optimized out>)
>    at 
> /home/andy/src/mxe-octave/tmp-stable-octave/octave-4.0.0/liboctave/array/
> Array.h:223
> #6  0x011e3b83 in ~MArray (this=0x1bb13a40, __in_chrg=<optimized out>)
>    at 
> /home/andy/src/mxe-octave/tmp-stable-octave/octave-4.0.0/liboctave/array/
> MArray.h:63
> #7  ~NDArray (this=0x1bb13a40, __in_chrg=<optimized out>)
>    at 
> /home/andy/src/mxe-octave/tmp-stable-octave/octave-4.0.0/liboctave/array/
> dNDArray.h:35
> #8  ~octave_base_matrix (this=0x1bb13a38, __in_chrg=<optimized out>)
>    at 
> /home/andy/src/mxe-octave/tmp-stable-octave/octave-4.0.0/libinterp/octave
> -value/ov-base-mat.h:68
> #9  ~octave_matrix (this=0x1bb13a38, __in_chrg=<optimized out>)
>    at 
> /home/andy/src/mxe-octave/tmp-stable-octave/octave-4.0.0/libinterp/octave
> -value/ov-re-mat.h:97
> 
> Any ideas what I could try?
> Thank you, Andy
> 

My initial thought would be that the “clear m” in the test script is forcing 
the destructor to be called and it is possible that stuff is still going on in 
the encoding process (ffmpeg is sometimes multithreaded depending on the codec, 
and there could still be file IO going on).

As a first test, I would put a big delay (say 5-10 seconds) between the 
‘endfor' and the ‘clear m'  in the avifile test. If it is just a matter of 
trying to delete the ffmpeg codec and other objects before they are ready to be 
deleted, that could cause a segfault. I know there is a chunk of code just 
previous to the segfault location that *should be* cleaning things up before 
closing everything, but maybe it isn’t cleaning up correctly?

John S.