[mythtv] Backend segfaulting repeatedly during recording DVB

Ed Wildgoose lists at wildgooses.com
Wed Feb 23 02:14:25 UTC 2005


> :) I also have the same problems. Trouble is it's rater hard to debug 
> and watch TV at the same time, and this crash does not happen often 
> for me.


Well, I am glad I am not alone at least!


>> Whilst we are talking valgrind.  I am assuming the following are 
>> harmless?  Can anyone translate why they come up at all?
>>
>> ==20552== Thread 10:
>> ==20552== Conditional jump or move depends on uninitialised value(s)
>> ==20552==    at 0x1CFBD40F: __udivdi3 (in 
>> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/libgcc_s.so.1)
>> ==20552==    by 0x805C9ED: EncoderLink::cacheFreeSpace() 
>> (encoderlink.cpp:183)
>> ==20552==    by 0x808EE7C: Scheduler::FillEncoderFreeSpaceCache() 
>> (scheduler.cpp:229)
>> ==20552==    by 0x8092B9D: Scheduler::RunScheduler() (scheduler.cpp:883)
>> ==20552==
>>
> If I'm not wrong, it means you are using the variable straight away 
> without initialising it. When I debug my mythbackend crash, it would 
> sometimes show this line. I think that part looks legit, since that 
> struct variable doesn't have any pointers inside that's invalid. but 
> somehow my mythbackend will sometimes crash here.


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);
        }


>> ==20552==
>> ==20552== Thread 20:
>> ==20552== Syscall param ioctl(generic) contains uninitialised or 
>> unaddressable byte(s)
>> ==20552==    at 0x1D06EA09: ioctl (in /lib/libc-2.3.4.so)
>> ==20552==    by 0x1BD8D44E: DVBRecorder::SetDemuxFilters() 
>> (dvbrecorder.cpp:346)
>> ==20552==    by 0x1BD8EDA5: DVBRecorder::StartRecording() 
>> (dvbrecorder.cpp:532)
>> ==20552==    by 0x1BD36DA1: SpawnEncode(void*) (tv_rec.cpp:48)
>> ==20552==  Address 0x1EF63C61 is on thread 20's stack
>>
> This is the part with the QValueList iterator right? Does that block 
> look ok? It looks legit to me (though I am not 100% sure as I dun use 
> QT containers)...  Again my mythbackend crashes here sometimes.


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


    // 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;
        }
    }



> Try these three changes and see if your still having problems. Please 
> post any gdb/valgrind logs when it crashes on you again. thanks.


Nope, doesn't help.


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

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"?

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?

Ed W
|

>
>
> Regards.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev




More information about the mythtv-dev mailing list