[mythtv] Backend segfaulting repeatedly during recording DVB
htpc at treblid.dyndns.org
Wed Feb 23 02:47:25 UTC 2005
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
> 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();
> 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
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
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
> 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 :(...
More information about the mythtv-dev