Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#2065 closed defect (worksforme)

Backend segfault when recording from two cards

Reported by: cizek@… Owned by: danielk
Priority: minor Milestone: 0.21
Component: dvb Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

The attached log and backtrace is from SVN 10569. It seems to work ok with only one card recording, but crashes pretty reliably when both are recording (two pchdtv-3000's)

If you need anything else let me know.

Attachments (8)

log.be.0717.194530.bz2 (45.9 KB) - added by anonymous 13 years ago.
mythbackend log file
gdb.txt.stopped.at.0717.211919 (17.6 KB) - added by anonymous 13 years ago.
gdb backtrace
gdb.txt.0811.0928 (71.8 KB) - added by anonymous 13 years ago.
core data from svn 10744
log.be.0811.0928.bz2 (119.6 KB) - added by anonymous 13 years ago.
log from crash of svn 10744
2065.patch (760 bytes) - added by danielk 13 years ago.
patch to help valgrind find pes packet parsing problems
val.txt.0815.183320 (2.9 KB) - added by anonymous 13 years ago.
valgrind output from patched mythbackend
log.glibc.fault (63.8 KB) - added by anonymous 13 years ago.
be log with glibc detected memory fault
gdb.txt.glibc.fault (68.1 KB) - added by anonymous 13 years ago.
be core dump from glibc detected fault

Download all attachments as: .zip

Change History (15)

Changed 13 years ago by anonymous

Attachment: log.be.0717.194530.bz2 added

mythbackend log file

Changed 13 years ago by anonymous

gdb backtrace

comment:1 Changed 13 years ago by danielk

Milestone: 0.20
Owner: changed from Isaac Richards to danielk
Version: head

comment:2 Changed 13 years ago by danielk

Resolution: invalid
Status: newclosed

Please reproduce with current svn head and use "mythbackend -v record,channel,siparser,file", attch info and then reopen the ticket.

I may need to provide you with a debugging patch before we can narrow this down, but the additional logging should give us a better idea of what is happening.

Changed 13 years ago by anonymous

Attachment: gdb.txt.0811.0928 added

core data from svn 10744

Changed 13 years ago by anonymous

Attachment: log.be.0811.0928.bz2 added

log from crash of svn 10744

comment:3 Changed 13 years ago by cizek@…

Resolution: invalid
Status: closedreopened

Just attached core output and log from a crash with SVN 10744.

It occasionally crashes with only one card recording, but crashes pretty frequently with both recording.

I've tried both valgrind and the stack_protector functionality within gcc 4.1 to no avail. I've also rebuilt mysql and qt to make sure they weren't walking on mythbackend.

If there's anything else you can suggest I'd appreciate it.

Thanks

Changed 13 years ago by danielk

Attachment: 2065.patch added

patch to help valgrind find pes packet parsing problems

comment:4 Changed 13 years ago by danielk

Component: mythtvdvb

Cizek, it appears the signal is very dirty. My guess is that some invalid packets are getting through and being parsed, causing us to read uninitialized data. The pes allocator is hiding this from valgrind. Please apply the attached patch and then run the recorder under valgrind. You probably only need to record one stream, the recorder shouldn't crash under valgrind, but it should report any invalid reads.

Changed 13 years ago by anonymous

Attachment: val.txt.0815.183320 added

valgrind output from patched mythbackend

Changed 13 years ago by anonymous

Attachment: log.glibc.fault added

be log with glibc detected memory fault

Changed 13 years ago by anonymous

Attachment: gdb.txt.glibc.fault added

be core dump from glibc detected fault

comment:5 Changed 13 years ago by cizek@…

I just attached three more files:

  • valgrind output using the above mentioned patch. This ran for 11+ hours w/o any problems.
  • backend log and core listing from a glibc abort with the following error message (with one recorder recording):
    *** glibc detected *** mythbackend: malloc(): memory corruption (fast): 0x0820e627 ***
    

comment:6 Changed 13 years ago by danielk

Milestone: 0.200.21
Resolution: worksforme
Status: reopenedclosed

Sorry, nothing useful in those :|

The valgrind log looks suspiciously small for 11 hours though, you might want to try that again, but first can you humour me and run memtest86 for a few hours? I would like to eliminate bad memory on your computer as a possibility, until then I'm closing the ticket. But please reopen if memtest86 doesn't report anything.

comment:7 Changed 13 years ago by anonymous

This was caused by a kernel memory debugging option I had selected a while back. I removed it a few days ago and it's been fine since then.

Thanks for the help, Daniel.

Note: See TracTickets for help on using tickets.