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

[John Swensen]

> 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.