From patchwork Mon May 14 21:22:56 2007 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Reinhard Nissl X-Patchwork-Id: 12463 Received: from mail.gmx.net ([213.165.64.20]) by www.linuxtv.org with smtp (Exim 4.50) id 1Hni0v-0002r2-Ht for vdr@linuxtv.org; Mon, 14 May 2007 23:23:29 +0200 Received: (qmail invoked by alias); 14 May 2007 21:22:57 -0000 Received: from p549330AE.dip0.t-ipconnect.de (EHLO [192.168.101.15]) [84.147.48.174] by mail.gmx.net (mp035) with SMTP; 14 May 2007 23:22:57 +0200 X-Authenticated: #527675 X-Provags-ID: V01U2FsdGVkX1+GIhdkhHWGcheQVZwQkx9wNktgVw1guFwC3YWExD fhBX4n+hlUSZb8 Message-ID: <4648D330.30004@gmx.de> Date: Mon, 14 May 2007 23:22:56 +0200 From: Reinhard Nissl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20060911 SUSE/1.5.0.10-1.1 Thunderbird/1.5.0.10 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: VDR Mailing List X-Y-GMX-Trusted: 0 Subject: [vdr] BUG: race condition triggered in cReceiver due to incorrect use by femon X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2007 21:23:29 -0000 Status: O X-Status: X-Keywords: X-UID: 12900 Hi, I've just got a pure virtual function call in cDevice::Action() for receiver[i]->Receive(b, TS_SIZE); It has happened while closing femon's OSD: (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7f2fc4e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #2 0xb7f2ba3c in _L_mutex_lock_88 () from /lib/libpthread.so.0 #3 0xb7f2b42d in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x08124281 in cMutex::Lock (this=0xb762c48) at thread.c:190 #5 0x080a7cdc in cThread::Lock (this=0xb762c38) at thread.h:91 #6 0x080a5548 in cDevice::Detach (this=0xb762c38, Receiver=0xb099ab0) at device.c:1298 #7 0x080effb9 in cReceiver::Detach (this=0xb099ab0) at receiver.c:60 #8 0x080f0090 in ~cReceiver (this=0xb099ab0) at receiver.c:43 #9 0xb799ac29 in cFemonReceiver::~cFemonReceiver () from /soft/vdr-1.4.6/lib/vdr/libvdr-femon.so.1.4.5 #10 0xb7998b05 in cFemonOsd::~cFemonOsd () from /soft/vdr-1.4.6/lib/vdr/libvdr-femon.so.1.4.5 #11 0x08131da7 in main (argc=20, argv=0xbf90e914) at vdr.c:885 #12 0xb7ce6f9c in __libc_start_main () from /lib/libc.so.6 #13 0x08091111 in _start () (gdb) cReceiver::~cReceiver() calls Detach(), but at that time, it is simply too late as the virtual method table entry for Receive() has already been restored to 0. I suggest to call Detach() from cFemonReceiver::~cFemonReceiver() to fix this issue. Furthermore I suggest to add some debug output to ~cReceiver() in the case where the receiver is still attached. I've been using femon for quite some time now and it was the first time, that VDR dumped a core regarding a pure virtual function call. Such a debug output would have triggered way more early. Bye. --- ../vdr-1.4.6-orig/receiver.c 2006-03-26 16:07:21.000000000 +0200 +++ receiver.c 2007-05-14 23:17:26.000000000 +0200 @@ -38,7 +39,11 @@ cReceiver::cReceiver(int Ca, int Priorit cReceiver::~cReceiver() { - Detach(); + if (device) { + esyslog("ERROR: cReceiver has not been detached yet! This is a design fault and VDR will segfault now!"); + fprintf(stderr, "ERROR: cReceiver has not been detached yet! This is a design fault and VDR will segfault now!\n"); + *(char *)0 = 0; + } } bool cReceiver::WantsPid(int Pid)