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

[JohnD]

> -----Original Message-----
> From: John Swensen [mailto:address@hidden
> Sent: Thursday, January 07, 2016 3:19 PM
> To: JohnD
> Cc: address@hidden; Andreas Weber
> Subject: Re: Request help debugging octave-video in mxe-octave
> 
> 
> > On Jan 7, 2016, at 12:01 PM, JohnD <address@hidden>
> wrote:
> >
> >
> >
> >> -----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
> >
> 
> That may be a problem, but I don’t think the default constructor is ever being
> called during the avifile test and I don’t ever see the warning "avifile: copy
> constructor shouldn't be called” that should occur if the copy constructor was
> actually being called.

Isnt the '=' operator going to do a similar thing - its going to blindly copy 
the av pointer between objects