[mythtv] Backend process dies at 4GB file limit? - coding hints wanted.... PATCH ATTACHED TOO

Buzz buzz at oska.com
Thu Jan 19 19:20:26 UTC 2006


 
Hi All.   I'm working on a solution to this thread and have got the
following steps working in my code (diff attached):

1) OS sends SIGXFSZ to mythbackend
2) backend captures said signal, squirrels it into a global called
"LastSignal", so anyone who wants to can look for it. (yes, I know globals
are bad, but signal handlers are worse.)
3) ThreadedFileWriter.cpp has an existing function called "safe_write" that
I've modified so that it checks for the signal(in the global) before trying
to write to any file.
4) safe_write: if a SIGXFSZ signal was received it "aborts" the in-progress
write (then-and-there, without flushing memory buffers to disk or anything),
returning an error.
5) safe_write is called from inside ThreadedFileWriter::DiskLoop.  The
return value of safe_write is tested in DiskLoop, and it causes both threads
(write and sync threads of ThreadedFileWriter) to be torn down, and the
ThreadedFileWriter to enter a state of "write error".
6)  next time the caller (RingBuffer.cpp) trys to call tfw->Write(...) it
fails, returning -1 up to the calling function (which is in RingBuffer.cpp -
Write), and the tfw is torn down, closing the open file handle, and cleaning
up.
7) RingBuffer.cpp already had the capability to return -1 or other errors,
so it's been tweaked to look at the return status of the tfw->Write call
too, and pass the error up if it occurs.

...now, I'm not sure where to take it from here.  

The signal is definitely being captured, and it's being passed all the way
back up to the RingBuffer, so I know that's working but....  Nothing else
(backend and/or frontend) seems to  recognise that the recording failed.
Should I go that far, or just barf the error message to the log, and leave
it at that?

IE: How do I make everything else recognise that the recording of this file
has aborted/failed?

Am I doing the right thing here... Or is there an easier way?


Buzz.


> -----Original Message-----
> From: mythtv-dev-bounces at mythtv.org 
> [mailto:mythtv-dev-bounces at mythtv.org] On Behalf Of Buzz
> Sent: Thursday, 19 January 2006 5:12 PM
> To: 'Development of mythtv'
> Subject: Re: [mythtv] Backend process dies at 4GB file limit? 
> -with backtrace as requested.
> 
> Mike,
> Thanks for the URL tip re gdb.   
> 
> In this case however, the BT I've given is enough to find the
> problem/solution:
> 
> *) OS is sending a SIGXFSZ to backend, backend is taking 
> default action which "coredump and exit".
> 
> Solution:
> 
> * capture SIGXFSZ, handle it gracefully.
> 
> Buzz
> 
> 
> > -----Original Message-----
> > From: mythtv-dev-bounces at mythtv.org
> > [mailto:mythtv-dev-bounces at mythtv.org] On Behalf Of Michael T. Dean
> > Sent: Thursday, 19 January 2006 4:57 PM
> > To: Development of mythtv
> > Subject: Re: [mythtv] Backend process dies at 4GB file limit? 
> > - with backtrace as requested.
> > 
> > Buzz wrote:
> > > All of backend log is available on request, and gdb is
> > still sitting
> > > there (for a few hours anyway)
> > good
> > > , incase you want me to do anything else with it.
> > > :-)   I'm a novice with GDB, so be gentle with me. (I don't 
> > know anything
> > > more than how to do 'run','c' and 'bt'.)
> > >   
> > Please http://www.mythtv.org/docs/mythtv-HOWTO-22.html#ss22.2
> > 
> > Mike
> > 
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev at mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> > 
> 
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: catch_and_handle_SIGXFSZ_diff.txt
Url: http://mythtv.org/pipermail/mythtv-dev/attachments/20060120/a09c8c70/catch_and_handle_SIGXFSZ_diff.txt


More information about the mythtv-dev mailing list