In article <514637FA.5080000@xxxxxxx> 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@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr