[mythtv] Backend segfaulting repeatedly during recording DVB

[Tom Hughes]

In message <421BEEBD.7030507 at treblid.dyndns.org>
          Tj <htpc at treblid.dyndns.org> wrote:

> Ed Wildgoose wrote:
> 
> > Well, I already worked out that much, but when I look at the code, it
> > looks fine to me?  Can't see what's uninitialised here?
> >
> >        struct statfs statbuf;
> >        if (statfs(recordfileprefix.ascii(), &statbuf) == 0)
> >        {
> >            freeSpace = statbuf.f_bavail / (1024*1024/statbuf.f_bsize);
> >        }
> >
> statbuf is declared and straightaway used in the if () condition. This
> should probably be allright since it's sort of a returned value. I guess
> if we set all the values in statbuf to 0 will kill the valgrind message.
> What I dun understand why my backtrace shows the if() condition
> sometimes when it crashes, and a corrupted stack message.

It should be fine - valgrind should mark the bits of statbuf which
the statfs system call fills in as valid when it returns. What version
of valgrind were you using?

> Do you remember when you do declare a variable as such, is it declared
> in the heap or stack?

That statbuf will be on the stack.

> Maybe try declaring statbuf as a pointer and alloc some memory to it? Or
> use auto_ptr if possible, and see if it stops the problem? Though I have
> no idea what difference it would make. The problem appears to be
> somewhere else.

None of that should be necessary.

> >    // Record all streams flagged for recording
> >    bool need_pcr_pid = true;
> >    QValueList<ElementaryPIDObject>::const_iterator es;
> >    for (es = m_pmt.Components.begin(); es != m_pmt.Components.end();
> > ++es)
> >    {
> >        if ((*es).Record)
> >        {
> >            OpenFilters((*es).PID, (*es).Type);
> >
> >            if ((*es).PID == m_pmt.PCRPID)
> >                need_pcr_pid = false;
> >        }
> >    }
> >
> >
> > Interestingly though I can't make the darn thing crash under
> > valgrind...  Now, I *think* valgrind might be enforcing some strict
> > 32bit alignment on memory accesses or similar?  If my crashes were an
> > "off by one" kind of bug, then this extra buffer might explain why
> > it's not dying under valgrind (not sure why it's not getting caught
> > though).
>
> I think valgrind should trap buffer overflows.

There is no extra alignment constraint under valgrind. The heap
layout may be different under valgrind but it should spot any attempt
to write beyond a heap block.

Tom

-- 
Tom Hughes (tom at compton.nu)
http://www.compton.nu/