[vdr] VDR 1.7 FreeBSD segfault when cutting recordings

2013-03-15 Thread Gerhard Brauer
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



bt.txt.gz
Description: Binary data
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR 1.7 FreeBSD segfault when cutting recordings

2013-03-16 Thread Gerhard Brauer
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
 

[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=50361344)
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/locale
Mar 16 08:30:09 s01 vdr: [50361344] loading plugin: 
/usr/local/lib/vdr/libvdr-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.conf
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.conf
Mar 16 08:30:09 s01 vdr: [50363392] video directory scanner thread started 
(pid=15494, tid=50363392)
Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'A - ATSC'
Mar 16 08:30:09 s01 vdr: [50365440] epg data reader thread started (pid=15494, 
tid=50365440)
Mar 16 08:30:09 s01 vdr: [50364416] video directory scanner thread started 
(pid=15494, tid=50364416)
Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'C - DVB-C'
Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'S - DVB-S'
Mar 16 08:30:09 s01 vdr: [50361344] registered source parameters for 'T - DVB-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,QAM16,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 
(pid=15494, tid=50366464)
Mar 16 08:30:09 s01 vdr: [50361344] initializing plugin: xineliboutput 
(1.0.90-cvs): X11/xine-lib Ausgabe-Plugin
Mar 16 08:30:09 s01 vdr: [50366464] cTimeMs: using monotonic clock (resolution 
is 70 ns)
Mar 16 08:30:09 s01 vdr: [50367488] section handler thread started (pid=15494, 
tid=50367488)
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 
(pid=15494, tid=50364416)
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=15494, 
tid=50365440)
Mar 16 08:30:10 s01 vdr: [50370560] Remote decoder/display server 
(cXinelibServer) thread started (pid=15494, tid=50370560)
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): Can't 
assign requested address)
Mar 16 08:30:10 s01 vdr: [disco

Re: [vdr] VDR 1.7 FreeBSD segfault when cutting recordings

2013-03-18 Thread Gerhard Brauer
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;

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR 1.7 FreeBSD segfault when cutting recordings

2013-03-18 Thread Gerhard Brauer
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


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR 1.7 FreeBSD segfault when cutting recordings

2013-03-18 Thread Gerhard Brauer
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 !) 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);
> &g