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 Klaus Schmidinger 

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;


___
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 g!) tried it with sizeof(MAXFRAMESIZE), the
result was not what i expected ;-)
But i consulted KR, 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

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

2013-03-18 Thread Klaus Schmidinger 

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 KR, 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;


For completeness, here's the patch as it will go into the current developer 
version.

Klaus
--- cutter.c	2013/02/17 14:11:03	2.24
+++ cutter.c	2013/03/18 09:40:49
@@ -362,11 +362,22 @@
   return true;
 }
 
+class cHeapBuffer {
+private:
+  uchar *buffer;
+public:
+  cHeapBuffer(int Size) { buffer = MALLOC(uchar, Size); }
+  ~cHeapBuffer() { free(buffer); }
+  operator uchar * () { return buffer; }
+  };
+
 bool cCuttingThread::FramesAreEqual(int Index1, int Index2)
 {
+  cHeapBuffer Buffer1(MAXFRAMESIZE);
+  cHeapBuffer Buffer2(MAXFRAMESIZE);
+  if (!Buffer1 || !Buffer2)
+ return false;
   bool Independent;
-  uchar Buffer1[MAXFRAMESIZE];
-  uchar Buffer2[MAXFRAMESIZE];
   int Length1;
   int Length2;
   if (LoadFrame(Index1, Buffer1, Independent, Length1)  LoadFrame(Index2, Buffer2, Independent, Length2)) {
@@ -386,12 +397,14 @@
 
 void cCuttingThread::GetPendingPackets(uchar *Data, int Length, int Index)
 {
+  cHeapBuffer Buffer(MAXFRAMESIZE);
+  if (!Buffer)
+ return;
   bool Processed[MAXPID] = { false };
   cPacketStorage PacketStorage;
   int64_t LastPts = lastVidPts + delta;// adding one frame length to fully cover the very last frame
   Processed[patPmtParser.Vpid()] = true; // we only want non-video packets
   for (int

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

2013-03-18 Thread Juergen Lock 
In article 5146cc8e.4070...@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




___
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-17 Thread Juergen Lock 
In article 20130316082610.gj23...@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:

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

2013-03-17 Thread Klaus Schmidinger 

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

___
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-17 Thread Juergen Lock 
In article 514637fa.5080...@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

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

[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