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:
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:
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:
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:
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:
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
On 18.03.2013 08:41, Gerhard Brauer wrote:
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
On Mon, Mar 18, 2013 at 09:13:02AM +0100, Klaus Schmidinger wrote:
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
In article 5146CC8E.4070808@tvdr.de you write:
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
-
Gerhard Brauer -
Juergen Lock -
Klaus Schmidinger