[vdr] VDR 1.7 FreeBSD segfault when cutting recordings

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Sun Mar 17 22:39:06 CET 2013


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



More information about the vdr mailing list