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

[JohnD]

> -----Original Message-----
> From: JohnD [mailto:address@hidden
> Sent: Thursday, January 07, 2016 8:02 AM
> To: address@hidden
> Cc: 'John Swensen'; 'Andreas Weber'
> Subject: Re: Request help debugging octave-video in mxe-octave
> 
> >
> > Message: 3
> > Date: Tue, 5 Jan 2016 10:21:55 -0800
> > From: John Swensen <address@hidden>
> > To: Andreas Weber <address@hidden>
> > Cc: octave-maintainers <address@hidden>
> > Subject: Re: Request help debugging octave-video in mxe-octave
> > Message-ID: <address@hidden>
> > Content-Type: text/plain; charset=utf-8
> >
> >
> > > 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/a
> > > rr
> > > ay/
> > > 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/a
> > > rr
> > > ay/
> > > 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/a
> > > rr
> > > ay/
> > > 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/a
> > > rr
> > > ay/
> > > 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/o
> > > ct
> > > ave
> > > -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/o
> > > ct
> > > ave
> > > -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.
> >
> 
> 
> Ok - I can see it on my build as well - it doesn't happen all the time
> 
> I used to see it crash on calling avifile before 1.2.1, but don't seem to
see it
> there anymore, but do see it when running the video test script

Not sure if this solves it, but ...

Looking at the video package source code:
AviFile has a copy constructor that is private, so normally wont be used.
However I beleive the default AviFile constructor DOES use it  with
*this=AviFile("default.avi")

The copy constructor blindly sets 'av' to point to the same value as what
the other constructor, so when it frees all the octave_base_value objects,
it has multiple base value objects trying to free the same 'av' pointer