Seqfault of cutting thread on "Low disk space!"

  Hi, 

we*) notice a seqfault of cutting Thread on "Low disk space!", if OSD
used during cutting process.

i think, reason is a call of a OSD function from background cutting
thread. 

I tested only on 1.3.32, but 1.3.37 should also affected 

(gdb) thread 5 
[Switching to thread 5 (process 4733)]#0  0xb7e68114 in ioctl ()
   from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7e68114 in ioctl () from /lib/tls/libc.so.6
#1  0x080aa202 in cDvbOsd::Cmd (this=0x8c9e710, cmd=OSD_Clear, color=0, x0=0,
    y0=0, x1=0, y1=0, data=0x0) at dvbosd.c:110
#2  0x080a9c13 in cDvbOsd (this=0x8c9e710, Left=54, Top=504, OsdDev=5)
    at dvbosd.c:63
#3  0x080aa816 in cDvbOsdProvider::CreateOsd (this=0x8c81930, Left=54, Top=504)
    at dvbosd.c:183
#4  0x080e4854 in cOsdProvider::NewOsd (Left=54, Top=504) at osd.c:738
#5  0x08110911 in cSkinSTTNGDisplayMessage (this=0x8c95570) at skinsttng.c:1052
#6  0x08111100 in cSkinSTTNG::DisplayMessage (this=0x8c819f0)
    at skinsttng.c:1117
#7  0x0810509e in cSkins::Message (this=0x81f73e4, Type=mtWarning,
    s=0x8143f3f "Platte beinahe voll!", Seconds=30) at skins.c:179
#8  0x080bb3d4 in cInterface::Confirm (this=0x8c818c0,
    s=0x8143f3f "Platte beinahe voll!", Seconds=30, WaitForTimeout=false)
    at interface.c:71
#9  0x080ece45 in AssertFreeDiskSpace (Priority=-1) at recording.c:147
#10 0x0809d62f in cCuttingThread::Action (this=0x8c92528) at cutter.c:86
#11 0x0811b716 in cThread::StartThread (Thread=0x8c92528) at thread.c:234
#12 0xb7fb8b63 in start_thread () from /lib/tls/libpthread.so.0
#13 0xb7e6f18a in clone () from /lib/tls/libc.so.6




Here a possibly solution : 

      }


*) I'm not the original bug reporter, but i could this seqfault
reproduce
http://www.vdr-portal.de/board/thread.php?threadid=42375&sid=


Cu,
Andreas
  

Andreas Brachold wrote:
> Hi, 
> 
> we*) notice a seqfault of cutting Thread on "Low disk space!", if OSD
> used during cutting process.
> 
> i think, reason is a call of a OSD function from background cutting
> thread. 
> 
> I tested only on 1.3.32, but 1.3.37 should also affected 
> 
> (gdb) thread 5 
> ...
> 
> Here a possibly solution : 
> 
> --- recording.c.org     2005-09-11 17:52:31.000000000 +0200
> +++ recording.c 2005-12-07 21:33:18.000000000 +0100
> @@ -144,7 +144,7 @@
>             }
>          // Unable to free disk space, but there's nothing we can do
> about that...
>          isyslog("...no old recording found, giving up");
> -        Interface->Confirm(tr("Low disk space!"), 30);
> +        Skins.QueueMessage(mtWarning, tr("Low disk space!"), 30);
>          }
>       LastFreeDiskCheck = time(NULL);
>       }

You're absolutely right - calling Interface->Confirm() from
a thread is a no-no. Silly me, telling others not to do this,
while doing it myself...

Thanks for the fix.

> *) I'm not the original bug reporter, but i could this seqfault
> reproduce
> http://www.vdr-portal.de/board/thread.php?threadid=42375&sid=
> 
> 
> Cu,
> Andreas

But I take it that you have suggested this fix, right?
If not, please tell the one who did to come forward so
that he can be given credit in the VDR/CONTRIBUTORS
file.

Klaus
  

Hallo Klaus,

ich glaube einen Bug gefunden zu haben, ich habe eine kanallliste von 
ca. 550 Einträgen. Wenn ich einen Kanal markiere (an pos 489) und dann 
sehr schnell zum Anfang blättere bleibt der vdr stehen und verbraucht 
100% cpu. Leider treten keine Einträge im Log auf.

cu
xpix
  

On Donnerstag 08 Dezember 2005 13:38, Frank Herrmann wrote:
> ich habe eine kanallliste von 
> ca. 550 Einträgen. Wenn ich einen Kanal markiere (an pos 489) und dann 
> sehr schnell zum Anfang blättere bleibt der vdr stehen und verbraucht 
> 100% cpu.

passiert das nur dann, wenn Du gerade ZDF oder Pro7 oder Sat1
empfängst? Mit anderen Worten wenn der Transfer modus aktiv ist?

Dann würde ich eine aktuelle Firmware versuchen.
  

Wolfgang Rohdewald schrieb:

>Dann würde ich eine aktuelle Firmware versuchen.
>
Hatte das Problem auch. Die FW-2622 war die Lösung. Kein Transfermodus 
mehr notwendig (und schnelles OSD). :-)
  

Hello and sorry for my mistake!

I have read a mail from Klaus and push button 'Reply' ;) I forget, this 
is a mail from the mailinglist.

Ok, i recreate the Question in english and in a new thread.

--------------

I have a channellist with more as 500 entrys, If i mark a channel at 
position and then jump from page to page very fast with the right or 
left button. Then vdr is freeze with more as 95% cpu and i must restart 
my vdr.

Wolfgang Rohdewald wrote:
> passiert das nur dann, wenn Du gerade ZDF oder Pro7 oder Sat1
> empfängst? Mit anderen Worten wenn der Transfer modus aktiv ist?

No, i looked in this moment the Phoenix channel.
  

On Thu, Dec 08, 2005 at 03:54:07PM +0100, Thomas Rausch wrote:
> Wolfgang Rohdewald schrieb:
> 
> >Dann würde ich eine aktuelle Firmware versuchen.
> >
> Hatte das Problem auch. Die FW-2622 war die Lösung. Kein Transfermodus 
> mehr notwendig (und schnelles OSD). :-)

Nevertheless ... IMHO the bug exist even with new firmware
and ... maybe for parallel recordings ... it should be fixed :)

         Werner
  

Dr. Werner Fink schrieb:

>On Thu, Dec 08, 2005 at 03:54:07PM +0100, Thomas Rausch wrote:
>  
>
>>Wolfgang Rohdewald schrieb:
>>    
>>
>>>Dann würde ich eine aktuelle Firmware versuchen.
>>>
>>>      
>>>
>>Hatte das Problem auch. Die FW-2622 war die Lösung. Kein Transfermodus 
>>mehr notwendig (und schnelles OSD). :-)
>>    
>>
>
>Nevertheless ... IMHO the bug exist even with new firmware
>and ... maybe for parallel recordings ... it should be fixed :)
>
Ok, but I has no more problems.  I draw Sat.1, ZDF and a radiosender on 
(3 different transponders at the same time).  I switch then to Pro7 and 
let me the channel list indicate. Then I mark a channel and leaf then as 
wild from beginning to end and back and so on (1965 transmitters).  No 
crash. :)