[mythtv] Backend segfaulting repeatedly during recording DVB

[Tj]

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.

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

Initially I thought "recordfileprefix.ascii()" is invalid or 
statbuf.f_bsize is 0, both doesn't seem to be the case.

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.

>
> Yeah, I already applied your suggestions, but it makes no difference.  
> I think we should apply the delete[] changes, but I have seen several 
> references which says they are identical functions under linux, it's 
> just that they cause crashes on other operating systems...
>
So it's not that part causing the problem... What's the backtrace like?

>
>    // 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.


> It dies happily under gdb and run standalone, both with debug and 
> release compile flags.  I can't quite see what gcc flags I would want 
> to emulate the valgrind memory accesses though.  Perhaps 
> "|-mpreferred-stack-boundary"?
>
One thing I'm always too lazy to do is to compile QT as debug for more 
informative backtraces. Do you think that will help? Also found out that 
we should turn off all gcc optimisations stuffs for valgrind to better 
trap errors.

> Grateful for any suggestions on gcc flags.  This would at least allow 
> me to narrow it down to a memory problem with something getting 
> trampled...  Perhaps it's possible in gdb to find out who owns the 
> variable above or below a given memory address?

Can you do that? Frankly I dun use gdb much so I dun really know how to 
use it.. :) I should learn to use gdb.. hee hee:)

Also, what did you do to make mythbackend crash? Did you find a reliable 
way? I always have to wait at least 2 days before it crashes, and 
debugging is slow as I have no idea how to crash it.

If only two of us are having this problems, I would think it's something 
else, like buggy a buggy c library or something we both happen to use :(...


Regards.