[vdr] VDR 1.7 FreeBSD segfault when cutting recordings

[Juergen Lock]

In article <514637FA.5080000 at 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