VDR 1.7 FreeBSD segfault when cutting recordings

  In article <20130316082610.GJ23851@t60.brauer.lan> you write:
>On Fri, Mar 15, 2013 at 10:54:04AM +0100, Gerhard Brauer wrote:
>> 
>> I never have any problem during other actions with the remote VDR
>> (recording, viewing, place cutting marks,...) _exept_ when i start
>> the cutting procedere itself with the keyboard shortcut "2".
>> Most times (> 95%) the remote vdr segfaults immidiatly. The file
>> structure is still created (%foobar ff.). In the few times when it
>> not segfaults then the cutting is done well without problems.
>
>Hello again,
>
>I've learned that i could also start the cutting process on the vdr
>server itself, without a frontend. With this i also (and 100%
>reproducable) got the segfault of the vdr.
>
>I start without a running vdr:
>s01# vdr -u vdr --edit=/video/Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.48.50.99.rec/
>and also with a still running vdr and call the --edit with another instance:
>vdr -u vdr -i 1 --edit=/video/Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.48.50.99.rec/
>
>From both tries i make backtraces with gdb, both differs only in
>thread numbering etc.
>So i attach the one with -i 1 instance, along with the vdr logfile
>output. Maybe one of you see a clearer picture why this segfaults
>happen here.
>
>I attach logfile sequence and backtrace output together.
> 
>Regards and TIA
> 
>        Gerhard
> 
>
>
>--M/SuVGWktc5uNpra
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: attachment; filename="log+backtrace.txt"
>Content-Transfer-Encoding: quoted-printable
>
>[Here i restarted the vdr on the server]
>
>Mar 16 08:30:09 s01 vdr: [50361344] VDR version 1.7.29 started
>Mar 16 08:30:09 s01 vdr: [50361344] switched to user 'vdr'
>Mar 16 08:30:09 s01 vdr: [50361344] running as daemon (tid=3D50361344)
>Mar 16 08:30:09 s01 vdr: [50361344] codeset is 'UTF-8' - known
>Mar 16 08:30:09 s01 vdr: [50361344] found 28 locales in /usr/local/share/lo=
>cale
>Mar 16 08:30:09 s01 vdr: [50361344] loading plugin: /usr/local/lib/vdr/libv=
>dr-xineliboutput.so.1.7.29
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/setup.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/sources.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/diseqc.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/scr.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/channels.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/timers.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/svdrphosts.c=
>onf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/remote.conf
>Mar 16 08:30:09 s01 vdr: [50361344] loading /usr/local/etc/vdr/keymacros.co=
>nf
>Mar 16 08:30:09 s01 vdr: [50363392] video directory scanner thread started =
>(pid=3D15494, tid=3D50363392)
>Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'A - A=
>TSC'
>Mar 16 08:30:09 s01 vdr: [50365440] epg data reader thread started (pid=3D1=
>5494, tid=3D50365440)
>Mar 16 08:30:09 s01 vdr: [50364416] video directory scanner thread started =
>(pid=3D15494, tid=3D50364416)
>Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'C - D=
>VB-C'
>Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'S - D=
>VB-S'
>Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'T - D=
>VB-T'
>Mar 16 08:30:09 s01 vdr: [50361344] probing /dev/dvb/adapter0/frontend0
>Mar 16 08:30:09 s01 vdr: [50365440] reading EPG data from /video/epg.data
>Mar 16 08:30:09 s01 vdr: [50361344] creating cDvbDevice
>Mar 16 08:30:09 s01 vdr: [50361344] new device number 1
>Mar 16 08:30:09 s01 vdr: [50361344] frontend 0/0 provides DVB-T with QPSK,Q=
>AM16,QAM64 ("DiBcom 7000PC")
>Mar 16 08:30:09 s01 vdr: [50361344] found 1 DVB device
>Mar 16 08:30:09 s01 vdr: [50366464] tuner on frontend 0/0 thread started (p=
>id=3D15494, tid=3D50366464)
>Mar 16 08:30:09 s01 vdr: [50361344] initializing plugin: xineliboutput (1.0=
>=2E90-cvs): X11/xine-lib Ausgabe-Plugin
>Mar 16 08:30:09 s01 vdr: [50366464] cTimeMs: using monotonic clock (resolut=
>ion is 70 ns)
>Mar 16 08:30:09 s01 vdr: [50367488] section handler thread started (pid=3D1=
>5494, tid=3D50367488)
>Mar 16 08:30:09 s01 vdr: [50361344] new device number 64
>Mar 16 08:30:09 s01 vdr: [50361344] setting primary device to 2
>Mar 16 08:30:09 s01 vdr: [50364416] video directory scanner thread ended (p=
>id=3D15494, tid=3D50364416)
>Mar 16 08:30:10 s01 vdr: [50361344] assuming manual start of VDR
>Mar 16 08:30:10 s01 vdr: [50361344] SVDRP listening on port 6419
>Mar 16 08:30:10 s01 vdr: [50361344] setting current skin to "lcars"
>Mar 16 08:30:10 s01 vdr: [50361344] loading /usr/local/etc/vdr/themes/lcars=
>-default.theme
>Mar 16 08:30:10 s01 vdr: [50361344] starting plugin: xineliboutput
>Mar 16 08:30:10 s01 vdr: [50365440] epg data reader thread ended (pid=3D154=
>94, tid=3D50365440)
>Mar 16 08:30:10 s01 vdr: [50370560] Remote decoder/display server (cXinelib=
>Server) thread started (pid=3D15494, tid=3D50370560)
>Mar 16 08:30:10 s01 vdr: [discovery] discovery_init: bind() failed
>Mar 16 08:30:10 s01 vdr: [discovery]    (ERROR (tools/vdrdiscovery.c,73): C=
>an't assign requested address)
>Mar 16 08:30:10 s01 vdr: [discovery] UDP broadcast send failed (discovery)
>Mar 16 08:30:10 s01 vdr: [discovery]    (ERROR (tools/vdrdiscovery.c,97): B=
>ad file descriptor)
>Mar 16 08:30:10 s01 vdr: [50363392] video directory scanner thread ended (p=
>id=3D15494, tid=3D50363392)
>Mar 16 08:30:10 s01 vdr: [50361344] switching to channel 16
>Mar 16 08:30:10 s01 vdr: [50371584] receiver on device 1 thread started (pi=
>d=3D15494, tid=3D50371584)
>Mar 16 08:30:10 s01 vdr: [67295232] TS buffer on device 1 thread started (p=
>id=3D15494, tid=3D67295232)
>Mar 16 08:30:10 s01 vdr: [50361344] OSD size changed to 720x576 @ 1.42222
>
>[Here 08:30:39 i started the --edit from another commandline on the server]
>
>Mar 16 08:30:39 s01 vdr: [50361344] loading /video/Die_Marx_Brothers_im_Kau=
>fhaus/2012-10-29.01.48.50.99.rec///marks.vdr
>Mar 16 08:30:39 s01 vdr: [50361344] loading /video/Die_Marx_Brothers_im_Kau=
>fhaus/2012-10-29.01.48.50.99.rec///marks.vdr
>Mar 16 08:30:39 s01 vdr: [50361344] removing /video/%Die_Marx_Brothers_im_K=
>aufhaus/2012-10-29.01.58.50.99.rec/001.vdr
>Mar 16 08:30:39 s01 vdr: [50361344] removing /video/%Die_Marx_Brothers_im_K=
>aufhaus/2012-10-29.01.58.50.99.rec/info.vdr
>Mar 16 08:30:39 s01 vdr: [50361344] removing /video/%Die_Marx_Brothers_im_K=
>aufhaus/2012-10-29.01.58.50.99.rec/index.vdr
>Mar 16 08:30:39 s01 vdr: [50361344] removing /video/%Die_Marx_Brothers_im_K=
>aufhaus/2012-10-29.01.58.50.99.rec
>Mar 16 08:30:39 s01 vdr: [50361344] creating directory /video/%Die_Marx_Bro=
>thers_im_Kaufhaus/2012-10-29.01.58.50.99.rec
>Mar 16 08:30:39 s01 vdr: [50361344] loading /video/Die_Marx_Brothers_im_Kau=
>fhaus/2012-10-29.01.48.50.99.rec///marks.vdr
>Mar 16 08:30:39 s01 vdr: [50361344] playing '/video/Die_Marx_Brothers_im_Ka=
>ufhaus/2012-10-29.01.48.50.99.rec//001.vdr'
>Mar 16 08:30:39 s01 vdr: [50361344] recording to '/video/%Die_Marx_Brothers=
>_im_Kaufhaus/2012-10-29.01.58.50.99.rec/001.vdr'
>Mar 16 08:30:39 s01 vdr: [50362368] video cutting thread started (pid=3D154=
>96, tid=3D50362368)
>Mar 16 08:30:40 s01 kernel: pid 15496 (vdr), uid 0: exited on signal 11 (co=
>re dumped)
>
>
>[backtrace output]
>Script started on Sat Mar 16 08:31:41 2013
>gdb /usr/local/bin/vdr ./vdr.core=0D
>GNU gdb 6.1.1 [FreeBSD]=0D
>Copyright 2004 Free Software Foundation, Inc.=0D
>GDB is free software, covered by the GNU General Public License, and you ar=
>e=0D
>welcome to change it and/or distribute copies of it under certain condition=
>s.=0D
>Type "show copying" to see the conditions.=0D
>There is absolutely no warranty for GDB.  Type "show warranty" for details.=
>=0D
>This GDB was configured as "amd64-marcel-freebsd"...=0D
>Core was generated by `vdr'.=0D
>Program terminated with signal 11, Segmentation fault.=0D
>Reading symbols from /usr/local/lib/libjpeg.so.11...done.=0D
>Loaded symbols for /usr/local/lib/libjpeg.so.11=0D
>Reading symbols from /lib/libthr.so.3...done.=0D
>Loaded symbols for /lib/libthr.so.3=0D
>Reading symbols from /usr/lib/librt.so.1...done.=0D
>Loaded symbols for /usr/lib/librt.so.1=0D
>Reading symbols from /lib/libutil.so.9...done.=0D
>Loaded symbols for /lib/libutil.so.9=0D
>Reading symbols from /usr/local/lib/libintl.so.9...done.=0D
>Loaded symbols for /usr/local/lib/libintl.so.9=0D
>Reading symbols from /usr/local/lib/libiconv.so.3...done.=0D
>Loaded symbols for /usr/local/lib/libiconv.so.3=0D
>Reading symbols from /usr/local/lib/libfreetype.so.9...done.=0D
>Loaded symbols for /usr/local/lib/libfreetype.so.9=0D
>Reading symbols from /usr/local/lib/libfontconfig.so.1...done.=0D
>Loaded symbols for /usr/local/lib/libfontconfig.so.1=0D
>Reading symbols from /usr/lib/libstdc++.so.6...done.=0D
>Loaded symbols for /usr/lib/libstdc++.so.6=0D
>Reading symbols from /lib/libm.so.5...done.=0D
>Loaded symbols for /lib/libm.so.5=0D
>Reading symbols from /lib/libgcc_s.so.1...done.=0D
>Loaded symbols for /lib/libgcc_s.so.1=0D
>Reading symbols from /lib/libc.so.7...done.=0D
>Loaded symbols for /lib/libc.so.7=0D
>Reading symbols from /lib/libz.so.6...done.=0D
>Loaded symbols for /lib/libz.so.6=0D
>Reading symbols from /usr/lib/libbz2.so.4...done.=0D
>Loaded symbols for /usr/lib/libbz2.so.4=0D
>Reading symbols from /usr/local/lib/libexpat.so.6...done.=0D
>Loaded symbols for /usr/local/lib/libexpat.so.6=0D
>Reading symbols from /libexec/ld-elf.so.1...done.=0D
>Loaded symbols for /libexec/ld-elf.so.1=0D
>#0  0x00000008023f93b5 in fprintf () from /lib/libc.so.7=0D
>[New Thread 803007800 (LWP 101624/vdr)]=0D
>[New Thread 803007400 (LWP 100464/vdr)]=0D
>(gdb) =07thread apl=07=08=1B[Kply all bt=0D
>=0D
>Thread 2 (Thread 803007400 (LWP 100464/vdr)):=0D
>#0  0x0000000800bf19bc in pthread_kill () from /lib/libthr.so.3=0D
>#1  0x0000000800bebdb3 in pthread_getschedparam () from /lib/libthr.so.3=0D
>#2  0x0000000800bf3dcd in pthread_cond_signal () from /lib/libthr.so.3=0D
>#3  0x00000000004f4694 in cCondWait::Wait (this=3D0x7fffffffd620, TimeoutMs=
>=3DVariable "TimeoutMs" is not available.=0D
>) at thread.c:78=0D
>#4  0x00000000004f480d in cCondWait::SleepMs (TimeoutMs=3D500) at thread.c:=
>67=0D
>#5  0x000000000046742a in CutRecording (=0D
>    FileName=3D0x7fffffffdd6f "/video/Die_Marx_Brothers_im_Kaufhaus/2012-10=
>-29.01.48.50.99.rec/") at cutter.c:334=0D
>#6  0x00000000004fdbe7 in main (argc=3D6, argv=3D0x7fffffffdad8) at vdr.c:2=
>78=0D
>=0D
>Thread 1 (Thread 803007800 (LWP 101624/vdr)):=0D
>#0  0x00000008023f93b5 in fprintf () from /lib/libc.so.7=0D
>#1  0x00000008023f08e8 in vsyslog () from /lib/libc.so.7=0D
>#2  0x00000000004f9fb0 in syslog_with_tid (priority=3D3, =0D
>    format=3D0x529408 "ERROR: syscall(SYS_ioprio_set ...) unsupported on Fr=
>eeBSD") at tools.c:51=0D
>#3  0x0000000000465d8b in cCuttingThread::Action (this=3D0x80309d140) at cu=
>tter.c:73=0D
>#4  0x00000000004f3e7c in cThread::StartThread (Thread=3D0x80309d140) at th=
>read.c:274=0D
>#5  0x0000000800bea274 in pthread_getprio () from /lib/libthr.so.3=0D
>#6  0x0000000000000000 in ?? ()=0D
>Cannot access memory at address 0x7fffffbfe000=0D
>(gdb) q=0D
>
>Script done on Sat Mar 16 08:32:50 2013
>
Ok I looked at cutter.c again and now I think I found the cause:
Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
default seems to be 2 MB on amd64 and MAXFRAMESIZE is almost 1 MB...
Try the patch below, you can put it in files/patch-z-cutter.c
in the port dir. (the thread.c part is FreeBSD port specific, it
caused a different crash with --edit.)

 HTH, :)
	Juergen
  

On 17.03.2013 21:52, Juergen Lock wrote:
> ...
> Ok I looked at cutter.c again and now I think I found the cause:
> Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
> default seems to be 2 MB on amd64 and MAXFRAMESIZE is almost 1 MB...
> Try the patch below, you can put it in files/patch-z-cutter.c
> in the port dir. (the thread.c part is FreeBSD port specific, it
> caused a different crash with --edit.)
>
>   HTH, :)
> 	Juergen
>
> --- cutter.c.orig
> +++ cutter.c
> @@ -83,7 +83,18 @@ void cCuttingThread::Action(void)
>        int LastIFrame = 0;
>        toMarks.Add(0);
>        toMarks.Save();
> +#ifdef __FreeBSD__
> +     // XXX save thread stack space
> +     uchar *buffer = MALLOC(uchar, MAXFRAMESIZE);
> +     uchar *buffer2 = MALLOC(uchar, MAXFRAMESIZE);
> +     if (buffer == NULL || buffer2 == NULL) {
> +        free(buffer);
> +        error = "malloc";
> +        return;
> +        }
> +#else
>        uchar buffer[MAXFRAMESIZE], buffer2[MAXFRAMESIZE];
> +#endif
>        int Length2;
>        bool CheckForSeamlessStream = false;
>        bool LastMark = false;
> @@ -216,6 +227,10 @@ void cCuttingThread::Action(void)
>                 }
>              }
>        Recordings.TouchUpdate();
> +#ifdef __FreeBSD__
> +     free(buffer);
> +     free(buffer2);
> +#endif
>        }
>     else
>        esyslog("no editing marks found!");

I assume this patch is against an older version of VDR, because in the
current developer version this looks different. However, there are still
places where two buffers with a size of MAXFRAMESIZE are allocated on the
stack. So I guess I will change these to be allocated on the heap for
version 2.0.

Klaus
  

In article <514637FA.5080000@tvdr.de> you write:
>On 17.03.2013 21:52, Juergen Lock wrote:
>> ...
>> Ok I looked at cutter.c again and now I think I found the cause:
>> Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
>> default seems to be 2 MB on amd64 and MAXFRAMESIZE is almost 1 MB...
>> Try the patch below, you can put it in files/patch-z-cutter.c
>> in the port dir. (the thread.c part is FreeBSD port specific, it
>> caused a different crash with --edit.)
>>
>>   HTH, :)
>> 	Juergen
>>
>> --- cutter.c.orig
>> +++ cutter.c
>> @@ -83,7 +83,18 @@ void cCuttingThread::Action(void)
>>        int LastIFrame = 0;
>>        toMarks.Add(0);
>>        toMarks.Save();
>> +#ifdef __FreeBSD__
>> +     // XXX save thread stack space
>> +     uchar *buffer = MALLOC(uchar, MAXFRAMESIZE);
>> +     uchar *buffer2 = MALLOC(uchar, MAXFRAMESIZE);
>> +     if (buffer == NULL || buffer2 == NULL) {
>> +        free(buffer);
>> +        error = "malloc";
>> +        return;
>> +        }
>> +#else
>>        uchar buffer[MAXFRAMESIZE], buffer2[MAXFRAMESIZE];
>> +#endif
>>        int Length2;
>>        bool CheckForSeamlessStream = false;
>>        bool LastMark = false;
>> @@ -216,6 +227,10 @@ void cCuttingThread::Action(void)
>>                 }
>>              }
>>        Recordings.TouchUpdate();
>> +#ifdef __FreeBSD__
>> +     free(buffer);
>> +     free(buffer2);
>> +#endif
>>        }
>>     else
>>        esyslog("no editing marks found!");
>
>I assume this patch is against an older version of VDR, because in the
>current developer version this looks different. However, there are still
>places where two buffers with a size of MAXFRAMESIZE are allocated on the
>stack. So I guess I will change these to be allocated on the heap for
>version 2.0.
>
Ah yes, I'm still at 1.7.29, sorry I should have said...

 Thanx! :)
	Juergen
  

On Sun, Mar 17, 2013 at 09:52:46PM +0100, Juergen Lock wrote:
> >
> Ok I looked at cutter.c again and now I think I found the cause:
> Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
> default seems to be 2 MB on amd64 and MAXFRAMESIZE is almost 1 MB...
> Try the patch below, you can put it in files/patch-z-cutter.c
> in the port dir. (the thread.c part is FreeBSD port specific, it
> caused a different crash with --edit.)

Hello!
Thanks for the patch and your time, i think we're on the way ;-)

The cutting process now works without segfaulting or unbehavior exit
of the vdr process itself - but during cutting i got A LOT of "frame
larger than buffer" x greater then 8 (8 is fix in all messages).
-----------
Mar 18 08:30:12 s01 vdr: [50364416] ERROR: frame larger than buffer (17392 > 8)
Mar 18 08:30:12 s01 vdr: [50364416] ERROR: frame larger than buffer (17514 > 8)
Mar 18 08:30:12 s01 vdr: [50364416] video cutting thread ended (pid=33513, tid=50364416)
Mar 18 08:30:13 s01 vdr: [50361344] info: Schnitt beendet
-----------
The cutting ends now always normally.

The cutted recording itself seems to be corrupted. When trying to
play it i got "incomplete PES packet":
-----------
Mar 18 08:23:05 s01 vdr: [54684672] receiver on device 1 thread ended (pid=33513, tid=54684672)
Mar 18 08:23:05 s01 vdr: [50363392] ERROR: incomplete PES packet!
Mar 18 08:23:11 s01 last message repeated 87971 times
-------------
until i stop playing the cutted video.

Same errors when doing it without a frontend/OSD from Terminal with
--edit and -i1. 

> 
>  HTH, :)
> 	Juergen

Regards and TIA
        Gerhard

> 
> --- cutter.c.orig
> +++ cutter.c
> @@ -83,7 +83,18 @@ void cCuttingThread::Action(void)
>       int LastIFrame = 0;
>       toMarks.Add(0);
>       toMarks.Save();
> +#ifdef __FreeBSD__
> +     // XXX save thread stack space
> +     uchar *buffer = MALLOC(uchar, MAXFRAMESIZE);
> +     uchar *buffer2 = MALLOC(uchar, MAXFRAMESIZE);
> +     if (buffer == NULL || buffer2 == NULL) {
> +        free(buffer);
> +        error = "malloc";
> +        return;
> +        }
> +#else
>       uchar buffer[MAXFRAMESIZE], buffer2[MAXFRAMESIZE];
> +#endif
>       int Length2;
>       bool CheckForSeamlessStream = false;
>       bool LastMark = false;
> @@ -216,6 +227,10 @@ void cCuttingThread::Action(void)
>                }
>             }
>       Recordings.TouchUpdate();
> +#ifdef __FreeBSD__
> +     free(buffer);
> +     free(buffer2);
> +#endif
>       }
>    else
>       esyslog("no editing marks found!");
> --- thread.c.orig
> +++ thread.c
> @@ -242,7 +242,7 @@ void cThread::SetPriority(int Priority)
>  void cThread::SetIOPriority(int Priority)
>  {
>  #ifdef __FreeBSD__
> -  esyslog("ERROR: syscall(SYS_ioprio_set ...) unsupported on FreeBSD");
> +  // esyslog("ERROR: syscall(SYS_ioprio_set ...) unsupported on FreeBSD");
>  #else
>    if (syscall(SYS_ioprio_set, 1, 0, (Priority & 0xff) | (2 << 13)) < 0) // best effort class
>       LOG_ERROR;
  

On Mon, Mar 18, 2013 at 08:41:00AM +0100, Gerhard Brauer wrote:
> 
> The cutted recording itself seems to be corrupted. When trying to
> play it i got "incomplete PES packet":
> -----------
> Mar 18 08:23:05 s01 vdr: [54684672] receiver on device 1 thread ended (pid=33513, tid=54684672)
> Mar 18 08:23:05 s01 vdr: [50363392] ERROR: incomplete PES packet!
> Mar 18 08:23:11 s01 last message repeated 87971 times
> -------------
> until i stop playing the cutted video.

Sorry, forgot to mention: I don't see anything during playing this
cutted video...

Regards and TIA
        Gerhard
  

On 18.03.2013 08:41, Gerhard Brauer wrote:
> On Sun, Mar 17, 2013 at 09:52:46PM +0100, Juergen Lock wrote:
>>>
>> Ok I looked at cutter.c again and now I think I found the cause:
>> Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
>> default seems to be 2 MB on amd64 and MAXFRAMESIZE is almost 1 MB...
>> Try the patch below, you can put it in files/patch-z-cutter.c
>> in the port dir. (the thread.c part is FreeBSD port specific, it
>> caused a different crash with --edit.)
>
> Hello!
> Thanks for the patch and your time, i think we're on the way ;-)
>
> The cutting process now works without segfaulting or unbehavior exit
> of the vdr process itself - but during cutting i got A LOT of "frame
> larger than buffer" x greater then 8 (8 is fix in all messages).
> -----------
> Mar 18 08:30:12 s01 vdr: [50364416] ERROR: frame larger than buffer (17392 > 8)
> Mar 18 08:30:12 s01 vdr: [50364416] ERROR: frame larger than buffer (17514 > 8)
> Mar 18 08:30:12 s01 vdr: [50364416] video cutting thread ended (pid=33513, tid=50364416)
> Mar 18 08:30:13 s01 vdr: [50361344] info: Schnitt beendet
> -----------
> The cutting ends now always normally.
>
> The cutted recording itself seems to be corrupted. When trying to
> play it i got "incomplete PES packet":
> -----------
> Mar 18 08:23:05 s01 vdr: [54684672] receiver on device 1 thread ended (pid=33513, tid=54684672)
> Mar 18 08:23:05 s01 vdr: [50363392] ERROR: incomplete PES packet!
> Mar 18 08:23:11 s01 last message repeated 87971 times
> -------------
> until i stop playing the cutted video.
>
> Same errors when doing it without a frontend/OSD from Terminal with
> --edit and -i1.

I guess the problem is that Juergen has allocated the buffers on the
heap, but did not change the places where the buffer size is determined
using sizeof(buffer) and sizeof(buffer2). If you replace these with
MAXFRAMESIZE it should work.

Klaus

>> --- cutter.c.orig
>> +++ cutter.c
>> @@ -83,7 +83,18 @@ void cCuttingThread::Action(void)
>>        int LastIFrame = 0;
>>        toMarks.Add(0);
>>        toMarks.Save();
>> +#ifdef __FreeBSD__
>> +     // XXX save thread stack space
>> +     uchar *buffer = MALLOC(uchar, MAXFRAMESIZE);
>> +     uchar *buffer2 = MALLOC(uchar, MAXFRAMESIZE);
>> +     if (buffer == NULL || buffer2 == NULL) {
>> +        free(buffer);
>> +        error = "malloc";
>> +        return;
>> +        }
>> +#else
>>        uchar buffer[MAXFRAMESIZE], buffer2[MAXFRAMESIZE];
>> +#endif
>>        int Length2;
>>        bool CheckForSeamlessStream = false;
>>        bool LastMark = false;
>> @@ -216,6 +227,10 @@ void cCuttingThread::Action(void)
>>                 }
>>              }
>>        Recordings.TouchUpdate();
>> +#ifdef __FreeBSD__
>> +     free(buffer);
>> +     free(buffer2);
>> +#endif
>>        }
>>     else
>>        esyslog("no editing marks found!");
>> --- thread.c.orig
>> +++ thread.c
>> @@ -242,7 +242,7 @@ void cThread::SetPriority(int Priority)
>>   void cThread::SetIOPriority(int Priority)
>>   {
>>   #ifdef __FreeBSD__
>> -  esyslog("ERROR: syscall(SYS_ioprio_set ...) unsupported on FreeBSD");
>> +  // esyslog("ERROR: syscall(SYS_ioprio_set ...) unsupported on FreeBSD");
>>   #else
>>     if (syscall(SYS_ioprio_set, 1, 0, (Priority & 0xff) | (2 << 13)) < 0) // best effort class
>>        LOG_ERROR;
  

On Mon, Mar 18, 2013 at 09:13:02AM +0100, Klaus Schmidinger wrote:
> On 18.03.2013 08:41, Gerhard Brauer wrote:
> >
> > The cutting process now works without segfaulting or unbehavior exit
> > of the vdr process itself - but during cutting i got A LOT of "frame
> > larger than buffer" x greater then 8 (8 is fix in all messages).
> > -----------
> > Mar 18 08:30:12 s01 vdr: [50364416] ERROR: frame larger than buffer (17392 > 8)
> > Mar 18 08:30:12 s01 vdr: [50364416] ERROR: frame larger than buffer (17514 > 8)
> > Mar 18 08:30:12 s01 vdr: [50364416] video cutting thread ended (pid=33513, tid=50364416)
> > Mar 18 08:30:13 s01 vdr: [50361344] info: Schnitt beendet
> > -----------
> > The cutting ends now always normally.
> 
> I guess the problem is that Juergen has allocated the buffers on the
> heap, but did not change the places where the buffer size is determined
> using sizeof(buffer) and sizeof(buffer2). If you replace these with
> MAXFRAMESIZE it should work.

Yes, this works fine. I've had to add this to Juergen's patch:
---------
@@ -108,7 +119,7 @@                                                                                                  
                  CurrentFileNumber = FileNumber;                                                                    
                  }                                                                                                  
               if (fromFile) {                                                                                       
-                 int len = ReadFrame(fromFile, buffer,  Length, sizeof(buffer));                                    
+                 int len = ReadFrame(fromFile, buffer,  Length, MAXFRAMESIZE);                                      
                  if (len < 0) {                                                                                     
                     error = "ReadFrame";                                                                            
                     break;                                                                                          
@@ -193,7 +204,7 @@                                                                                                  
                     if (FileNumber != CurrentFileNumber)                                                            
                        fromFile = fromFileName->SetOffset(FileNumber, FileOffset);                                  
                     if (fromFile) {                                                                                 
-                       int len = ReadFrame(fromFile, buffer2, Length2, sizeof(buffer2));                            
+                       int len = ReadFrame(fromFile, buffer2, Length2, MAXFRAMESIZE);                               
                        if (len >= 0 && len == Length2)                                                              
                           CheckForSeamlessStream = true;                                                            
                        }
---------------

First I'm (me.noob <g>!) tried it with sizeof(MAXFRAMESIZE), the
result was not what i expected ;-)
But i consulted K&R, both mean heap and stack were realy nice
things... Hej, i'm a ruby guy, we have garbage collectors ;-)

I think Juergen will make a "final patch", i don't know if above
changes are well for all platforms, maybe a #ifdef __FreeBSD__ is
needed.
But for me: it works!

Thanks for a wonderfull piece oft software!
> 
> Klaus
> 

Regards
        Gerhard

> >> --- cutter.c.orig
> >> +++ cutter.c
> >> @@ -83,7 +83,18 @@ void cCuttingThread::Action(void)
> >>        int LastIFrame = 0;
> >>        toMarks.Add(0);
> >>        toMarks.Save();
> >> +#ifdef __FreeBSD__
> >> +     // XXX save thread stack space
> >> +     uchar *buffer = MALLOC(uchar, MAXFRAMESIZE);
> >> +     uchar *buffer2 = MALLOC(uchar, MAXFRAMESIZE);
> >> +     if (buffer == NULL || buffer2 == NULL) {
> >> +        free(buffer);
> >> +        error = "malloc";
> >> +        return;
> >> +        }
> >> +#else
> >>        uchar buffer[MAXFRAMESIZE], buffer2[MAXFRAMESIZE];
> >> +#endif
> >>        int Length2;
> >>        bool CheckForSeamlessStream = false;
> >>        bool LastMark = false;
> >> @@ -216,6 +227,10 @@ void cCuttingThread::Action(void)
> >>                 }
> >>              }
> >>        Recordings.TouchUpdate();
> >> +#ifdef __FreeBSD__
> >> +     free(buffer);
> >> +     free(buffer2);
> >> +#endif
> >>        }
> >>     else
> >>        esyslog("no editing marks found!");
> >> --- thread.c.orig
> >> +++ thread.c
> >> @@ -242,7 +242,7 @@ void cThread::SetPriority(int Priority)
> >>   void cThread::SetIOPriority(int Priority)
> >>   {
> >>   #ifdef __FreeBSD__
> >> -  esyslog("ERROR: syscall(SYS_ioprio_set ...) unsupported on FreeBSD");
> >> +  // esyslog("ERROR: syscall(SYS_ioprio_set ...) unsupported on FreeBSD");
> >>   #else
> >>     if (syscall(SYS_ioprio_set, 1, 0, (Priority & 0xff) | (2 << 13)) < 0) // best effort class
> >>        LOG_ERROR;
> 
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  

In article <5146CC8E.4070808@tvdr.de> you write:
>On 18.03.2013 08:41, Gerhard Brauer wrote:
>> On Sun, Mar 17, 2013 at 09:52:46PM +0100, Juergen Lock wrote:
>>>>
>>> Ok I looked at cutter.c again and now I think I found the cause:
>>> Linux must default to bigger thread stacks than FreeBSD, FreeBSD's
>>> default seems to be 2 MB on amd64 and MAXFRAMESIZE is almost 1 MB...
>>> Try the patch below, you can put it in files/patch-z-cutter.c
>>> in the port dir. (the thread.c part is FreeBSD port specific, it
>>> caused a different crash with --edit.)
>>
>> Hello!
>> Thanks for the patch and your time, i think we're on the way ;-)
>>
>> The cutting process now works without segfaulting or unbehavior exit
>> of the vdr process itself - but during cutting i got A LOT of "frame
>> larger than buffer" x greater then 8 (8 is fix in all messages).
>> -----------
>> Mar 18 08:30:12 s01 vdr: [50364416] ERROR: frame larger than buffer (17392 > 8)
>> Mar 18 08:30:12 s01 vdr: [50364416] ERROR: frame larger than buffer (17514 > 8)
>> Mar 18 08:30:12 s01 vdr: [50364416] video cutting thread ended (pid=33513, tid=50364416)
>> Mar 18 08:30:13 s01 vdr: [50361344] info: Schnitt beendet
>> -----------
>> The cutting ends now always normally.
>>
>> The cutted recording itself seems to be corrupted. When trying to
>> play it i got "incomplete PES packet":
>> -----------
>> Mar 18 08:23:05 s01 vdr: [54684672] receiver on device 1 thread ended (pid=33513, tid=54684672)
>> Mar 18 08:23:05 s01 vdr: [50363392] ERROR: incomplete PES packet!
>> Mar 18 08:23:11 s01 last message repeated 87971 times
>> -------------
>> until i stop playing the cutted video.
>>
>> Same errors when doing it without a frontend/OSD from Terminal with
>> --edit and -i1.
>
>I guess the problem is that Juergen has allocated the buffers on the
>heap, but did not change the places where the buffer size is determined
>using sizeof(buffer) and sizeof(buffer2). If you replace these with
>MAXFRAMESIZE it should work.
>
Oh haha I'm sorry, how could I have missed that...  I'll fix it tonight
and probably commit the working :) fix to ports.

 Thanx!
	Juergen

>Klaus
>
>>> --- cutter.c.orig
>>> +++ cutter.c
>>> @@ -83,7 +83,18 @@ void cCuttingThread::Action(void)
>>>        int LastIFrame = 0;
>>>        toMarks.Add(0);
>>>        toMarks.Save();
>>> +#ifdef __FreeBSD__
>>> +     // XXX save thread stack space
>>> +     uchar *buffer = MALLOC(uchar, MAXFRAMESIZE);
>>> +     uchar *buffer2 = MALLOC(uchar, MAXFRAMESIZE);
>>> +     if (buffer == NULL || buffer2 == NULL) {
>>> +        free(buffer);
>>> +        error = "malloc";
>>> +        return;
>>> +        }
>>> +#else
>>>        uchar buffer[MAXFRAMESIZE], buffer2[MAXFRAMESIZE];
>>> +#endif
>>>        int Length2;
>>>        bool CheckForSeamlessStream = false;
>>>        bool LastMark = false;
>>> @@ -216,6 +227,10 @@ void cCuttingThread::Action(void)
>>>                 }
>>>              }
>>>        Recordings.TouchUpdate();
>>> +#ifdef __FreeBSD__
>>> +     free(buffer);
>>> +     free(buffer2);
>>> +#endif
>>>        }
>>>     else
>>>        esyslog("no editing marks found!");
>>> --- thread.c.orig
>>> +++ thread.c
>>> @@ -242,7 +242,7 @@ void cThread::SetPriority(int Priority)
>>>   void cThread::SetIOPriority(int Priority)
>>>   {
>>>   #ifdef __FreeBSD__
>>> -  esyslog("ERROR: syscall(SYS_ioprio_set ...) unsupported on FreeBSD");
>>> +  // esyslog("ERROR: syscall(SYS_ioprio_set ...) unsupported on FreeBSD");
>>>   #else
>>>     if (syscall(SYS_ioprio_set, 1, 0, (Priority & 0xff) | (2 << 13)) < 0) // best effort class
>>>        LOG_ERROR;
>
>_______________________________________________
>vdr mailing list
>vdr@linuxtv.org
>http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>