Opened 18 years ago
Closed 18 years ago
#1564 closed defect (worksforme)
SEGFAULT in SIParser::CheckTrackers
| Reported by: | anonymous | Owned by: | danielk |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.20 |
| Component: | dvb | Version: | head |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
Attached is a backtrace and log for a segfault in SIParser. This same error happened 6 times this afternoon.
I'm running svn 9409 in Chicago, IL, USA.
If you need any additional info let me knw and I'll provide what I can.
Attachments (4)
Change History (13)
Changed 18 years ago by
| Attachment: | gdb.txt.stopped.at.0321.164452 added |
|---|
Changed 18 years ago by
| Attachment: | log.be.0321.151608.tail added |
|---|
comment:1 Changed 18 years ago by
| Milestone: | → 0.20 |
|---|---|
| Version: | → head |
comment:2 Changed 18 years ago by
I dug through the logs and backtrace and I think it's related to a race condition when the DVBSIParser is created. The base thread and SystemInfoThread? both use pnum_pid with no synchronization. (This is visible in the log file in threads 0xb340ebb0 and 0xacfc4bb0 - for threadid info see trac #1344)
I've attached a patch that creates a mutex lock for this.
If you need any clarification let me know,
Bill
Changed 18 years ago by
| Attachment: | pnum_lock.patch added |
|---|
comment:3 Changed 18 years ago by
| Component: | mythtv → dvb |
|---|---|
| Owner: | changed from Isaac Richards to danielk |
| Status: | new → assigned |
comment:4 Changed 18 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:5 Changed 18 years ago by
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
This changeset causes the backend to deadlock waiting for mutexes.
I have two tuners, so there are always two eitscanners running concurrently, thus there are always two sets of threads running causing the deadlock.
comment:6 Changed 18 years ago by
Stuart, a backtrace might help...
But first you might want to try the patch I just attached to the ticket.
comment:7 Changed 18 years ago by
FWIW: I tried using pmap_lock and got a similar result (deadlock). Using the new mutex (in pnum_lock.patch) has worked for me since yesterday.
Going beyond. The problem I found was when a distinct scanner was created. The constructor for DVBSIParser creates a new thread to run "siparser->StartSectionReader?()" which calls "SIParser::CheckTrackers?()". After the creation of the DVBSIParser object, we call ReinitSIParser() in the original thread. ReinitSIParser() (through a called function) clears pnum_pid, potentially at the same time that CheckTrackers?() is using pnum_pid. I'm very sure this "clear while in use" is what caused my crash.
I have two tuners, but I think that just doubles the odds that this will happen. I don't think there's any interaction between the two.
Anyway, YMMV, Hope this helps. If you have any questions for me you're welcome to email me direct.
Bill
comment:8 Changed 18 years ago by
comment:9 Changed 18 years ago by
| Resolution: | → worksforme |
|---|---|
| Status: | reopened → closed |
closing, no followup on what the real problem is.
can you run the backend through valgrind and see if anything turns up, the values for pid & co look pretty weird. I suspect a memory problem.