Opened 18 years ago
Closed 18 years ago
Last modified 18 years ago
#2065 closed defect (worksforme)
Backend segfault when recording from two cards
| Reported by: | 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)
Change History (15)
Changed 18 years ago by
| Attachment: | log.be.0717.194530.bz2 added |
|---|
comment:1 Changed 18 years ago by
| Milestone: | → 0.20 |
|---|---|
| Owner: | changed from Isaac Richards to danielk |
| Version: | → head |
comment:2 Changed 18 years ago by
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
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.
comment:3 Changed 18 years ago by
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
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 18 years ago by
| Attachment: | 2065.patch added |
|---|
patch to help valgrind find pes packet parsing problems
comment:4 Changed 18 years ago by
| Component: | mythtv → dvb |
|---|
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 18 years ago by
| Attachment: | val.txt.0815.183320 added |
|---|
valgrind output from patched mythbackend
Changed 18 years ago by
| Attachment: | gdb.txt.glibc.fault added |
|---|
be core dump from glibc detected fault
comment:5 Changed 18 years ago by
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 18 years ago by
| Milestone: | 0.20 → 0.21 |
|---|---|
| Resolution: | → worksforme |
| Status: | reopened → closed |
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 18 years ago by
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.
mythbackend log file