Hello,
i'm new on this list and my English is not the best...
I'm using VDR 1.7 headless on a FreeBSD machine. Interaction with this vdr server is done via vdr-sfxe from the xineliboutput plugin.
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.
I have contacted the FreeBSD maintainer of the vdr port and he advised to do a gdb backtrace on the generated coredump file. After seeing the backtrace he has no solution and told me to post better here on the list. I attach the gdb backtrace output with this mail (i hope the mailinglist allow attached file). Maybe you have a solution and/or an idea how to solve this. Of course i could do further tests or debugging, the segfault is well to reproduce here ;-)
Sometimes (but not so often and reproducable), when the cutting process/thread is not segfaulting, i got also an dying vdr process with signal 10 (bus error). That's when i use "backspace" to close the well cutted recording, normally it would go back to the current TV channel. Don't know if this is in some relation with the segfault/signal 11 I often have. This rare error i also got only during the cutting procedere, i could never reproduce it during watching TV or recordings.
Some infos on hardware and software versions of the (vdr) server: --------------------- FreeBSD 9.0-RELEASE-p3 amd64 CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1699.36-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) real memory = 8589934592 (8192 MB) avail memory = 7809277952 (7447 MB)
Filesystem ZFS
vdr-1.7.29_2 vdr-plugin-xineliboutput-1.0.90s20120511_6 ----------------------- Log output when the vdr dies with signal 11 (this is not from the attached backtrace): Mar 15 10:44:00 s01 vdr: [50363392] setting audio track to 1 (0) Mar 15 10:44:00 s01 vdr: [50364416] TS buffer on device 1 thread ended (pid=8844, tid=50364416) Mar 15 10:44:00 s01 vdr: [50365440] buffer stats: 34404 (1%) used Mar 15 10:44:00 s01 vdr: [50365440] receiver on device 1 thread ended (pid=8844, tid=50365440) Mar 15 10:44:17 s01 vdr: [50361344] playing '/video/Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.48.50.99.rec/002.vdr' Mar 15 10:44:19 s01 vdr: [50363392] SetBrokenLink: no GOP header found in video packet Mar 15 10:44:31 s01 vdr: [50361344] loading /video/Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.48.50.99.rec//marks.vdr Mar 15 10:44:31 s01 vdr: [50361344] creating directory /video/%Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.58.50.99.rec Mar 15 10:44:31 s01 vdr: [50361344] removing /video/%Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.58.50.99.del/index.vdr Mar 15 10:44:31 s01 vdr: [50361344] removing /video/%Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.58.50.99.del/001.vdr Mar 15 10:44:31 s01 vdr: [50361344] removing /video/%Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.58.50.99.del/info.vdr Mar 15 10:44:31 s01 vdr: [50361344] removing /video/%Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.58.50.99.del Mar 15 10:44:31 s01 vdr: [50361344] loading /video/Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.48.50.99.rec//marks.vdr Mar 15 10:44:31 s01 vdr: [50361344] playing '/video/Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.48.50.99.rec/001.vdr' Mar 15 10:44:31 s01 vdr: [50361344] recording to '/video/%Die_Marx_Brothers_im_Kaufhaus/2012-10-29.01.58.50.99.rec/001.vdr' Mar 15 10:44:31 s01 vdr: [58882048] video cutting thread started (pid=8844, tid=58882048) Mar 15 10:44:32 s01 kernel: pid 8844 (vdr), uid 938: exited on signal 11 (core dumped) -------------------------
From my low experience (I'm not a C developer) i think it could be a thread
timing problem, maybe FreeBSD special and in relation with the ZFS filesystem. Suspicios is IMHO that an error occurs only in the cutting procedere.
So, do you smell antyhing like a bug or similar ;-) Any ideas what i could do or test/debug to get rid off this error?
Regards and TIA
Gerhard
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
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
--- 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 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 spaceuchar *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 spaceuchar *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 spaceuchar *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 spaceuchar *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 spaceuchar *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
On 18.03.2013 10:10, Gerhard Brauer wrote:
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 spaceuchar *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;
For completeness, here's the patch as it will go into the current developer version.
Klaus
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 spaceuchar *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
-
Gerhard Brauer -
Juergen Lock -
Klaus Schmidinger