[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