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
