Opened 13 years ago

Closed 13 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)

gdb.txt.stopped.at.0321.164452 (9.4 KB) - added by anonymous 13 years ago.
log.be.0321.151608.tail (109.9 KB) - added by anonymous 13 years ago.
pnum_lock.patch (5.1 KB) - added by cizek@… 13 years ago.
1564.patch (476 bytes) - added by danielk 13 years ago.
make lock recursive

Download all attachments as: .zip

Change History (13)

Changed 13 years ago by anonymous

Changed 13 years ago by anonymous

Attachment: log.be.0321.151608.tail added

comment:1 Changed 13 years ago by danielk

Milestone: 0.20
Version: head

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.

comment:2 Changed 13 years ago by cizek@…

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 13 years ago by cizek@…

Attachment: pnum_lock.patch added

comment:3 Changed 13 years ago by danielk

Component: mythtvdvb
Owner: changed from Isaac Richards to danielk
Status: newassigned

comment:4 Changed 13 years ago by danielk

Resolution: fixed
Status: assignedclosed

(In [9466]) Closes #1564, by applying modified patch.

comment:5 Changed 13 years ago by Stuart Auchterlonie

Resolution: fixed
Status: closedreopened

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.

Changed 13 years ago by danielk

Attachment: 1564.patch added

make lock recursive

comment:6 Changed 13 years ago by danielk

Stuart, a backtrace might help...

But first you might want to try the patch I just attached to the ticket.

comment:7 Changed 13 years ago by cizek@…

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 13 years ago by danielk

(In [9482]) References #1564. Revert [9466] until we figure out what the problem is.

comment:9 Changed 13 years ago by danielk

Resolution: worksforme
Status: reopenedclosed

closing, no followup on what the real problem is.

Note: See TracTickets for help on using tickets.