Mailing List Archive

On Sun, Sep 29, 2002 at 12:03:53AM -0400, Isaac Richards wrote:

> So, recorded a show tonight. Went to play it back, and it crashed the
> player. Investigated, and found out that there were the status messages
> that should've been printed to the console _in_ the file. Bad data in the
> file = some bad reads = boom, dead player. I've added more checks to the
> stream parser, so that it seems to fix playing on this file, but the error
> itself is what's weird -- anyone know how the stdout/err could get
> redirected to a file, without me calling dup or dup2?

Various kinds of memory corruption could cause this, but I'd be surprised if
it didn't crash the recorder at the same time.

--
- mdz

On Sunday 29 September 2002 12:03 am, Isaac Richards wrote:
> So, recorded a show tonight. Went to play it back, and it crashed the
> player. Investigated, and found out that there were the status messages
> that should've been printed to the console _in_ the file. Bad data in the
> file = some bad reads = boom, dead player. I've added more checks to the
> stream parser, so that it seems to fix playing on this file, but the error
> itself is what's weird -- anyone know how the stdout/err could get
> redirected to a file, without me calling dup or dup2?

Ah-ha, figured it out, nevermind =)

I was dumb and missed initializing one of the file descriptor variables in one
of the constructors to the RingBuffer class. If it happened to get
initialized to STDOUT_FILENO, when the RingBuffer was destroyed, it'd close
stdout. Next time the RingBuffer was created (say, the next time a program
was recorded), the output file would get created with the first available
file descriptor -- STDOUT_FILENO. So, any cout's or printf's would go to the
file from then on.

Isaac