[vdr] Re: VDR 1.3.6 Segmentation fault in pthread_setschedparam

[Seppo Ingalsuo <seppo.ingalsuo@iki.fi>]

Here is a bit more information. When running vdr in gdb the segfault
location is not reported to be the same:

vdr@napsu:/home/seppo/src/vdrbuild-1903/vdr-1.3.6$ gdb
/usr/local/bin/vdr
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-linux"...
(gdb) run -c/etc/vdr -v/opt/vdr -E/var/log/dvb -L/usr/local/lib/vdr
-Pdxr3
Starting program: /usr/local/bin/vdr -c/etc/vdr -v/opt/vdr
-E/var/log/dvb -L/usr/local/lib/vdr -Pdxr3
[New Thread 1076298976 (LWP 917)]
[New Thread 1087056816 (LWP 921)]
[New Thread 1095445424 (LWP 922)]
[New Thread 1104174000 (LWP 924)]
[New Thread 1112562608 (LWP 925)]
[New Thread 1120951216 (LWP 926)]
[New Thread 1129339824 (LWP 927)]
 
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076298976 (LWP 917)]
0x40047d1c in pthread_cancel () from /lib/tls/libpthread.so.0
(gdb) where
#0  0x40047d1c in pthread_cancel () from /lib/tls/libpthread.so.0
#1  0x402ae676 in ~cDxr3SafeCloseThread (this=0x83a9f80) at
dxr3abstractiondevice.h:147
#2  0x402adec5 in cDxr3AbsDevice::NonBlockingCloseOpen()
(this=0x83a8af0) at dxr3abstractiondevice.c:800
#3  0x402ada44 in cDxr3AbsDevice::Resuscitation() (this=0x83a8af0) at
dxr3abstractiondevice.c:705
#4  0x402abf00 in cDxr3AbsDevice::SetAudioAnalog() (this=0x83a8af0) at
dxr3abstractiondevice.c:118
#5  0x402abdef in cDxr3AbsDevice (this=0x83a8af0) at
dxr3abstractiondevice.c:98
#6  0x402aafe7 in cDxr3AbsDevice::Instance() () at
dxr3abstractiondevice.c:38
#7  0x402a7ea1 in cDxr3Device::Instance() () at dxr3device.c:116
#8  0x402a6f51 in cPluginDxr3::Initialize() (this=0x8143328) at
dxr3.c:172
#9  0x080ab8d0 in cPluginManager::InitializePlugins() (this=0xbffff9c0)
at plugin.c:310
#10 0x080be093 in main (argc=6, argv=0xbffffac4) at vdr.c:385
(gdb)

Now it looks more like dxr3 plugin problem.


pe, 2004-03-19 kello 21:35, Seppo Ingalsuo kirjoitti:
> Hi,
> 
> Some other people on this list seem to have working dxr3 and Linux 2.6
> setups. I get a segfault in vdr 1.3.6 start. It might be relatex to dxr3
> plugin or Debian Sarge and Linux 2.6.3. Any ideas what goes wrong? 
> 
> vdr@napsu:~$ gdb /usr/local/bin/vdr --core=core.31861
> GNU gdb 6.0
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "i386-linux"...
> Core was generated by `vdr -c/etc/vdr -v/opt/vdr -E/var/log/dvb
> -L/usr/local/lib/vdr -r/usr/local/shar'.
> Program terminated with signal 11, Segmentation fault.
>  
> warning: current_sos: Can't read pathname for load map: Input/output
> error
>  
> Reading symbols from /usr/lib/libjpeg.so.62...done.
> Loaded symbols for /usr/lib/libjpeg.so.62
> Reading symbols from /lib/tls/libpthread.so.0...done.
> Loaded symbols for /lib/tls/libpthread.so.0
> Reading symbols from /lib/tls/libdl.so.2...done.
> Loaded symbols for /lib/tls/libdl.so.2
> Reading symbols from /usr/lib/libstdc++.so.5...done.
> Loaded symbols for /usr/lib/libstdc++.so.5
> Reading symbols from /lib/tls/libm.so.6...done.
> Loaded symbols for /lib/tls/libm.so.6
> Reading symbols from /lib/libgcc_s.so.1...done.
> Loaded symbols for /lib/libgcc_s.so.1
> Reading symbols from /lib/tls/libc.so.6...done.
> Loaded symbols for /lib/tls/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> Reading symbols from /usr/local/lib/vdr/libvdr-dxr3.so.1.3.6...done.
> Loaded symbols for /usr/local/lib/vdr/libvdr-dxr3.so.1.3.6
> #0  0x40045e9a in pthread_setschedparam () from /lib/tls/libpthread.so.0
> (gdb) where
> #0  0x40045e9a in pthread_setschedparam () from /lib/tls/libpthread.so.0
> 
> I tried to comment out pthread_setschedparam calls (for adjusting
> scheduling I think) from dxr3 plugin but it didn't have effect. I got
> the same segfault. There is also one in vdr's thread.c. 
> 
> bool cThread::Start(void)
> {
>   if (!running) {
>      running = true;
>      parentTid = pthread_self();
>      pthread_create(&childTid, 
>        NULL, (void *(*) (void *))&StartThread, (void *)this);
>      pthread_setschedparam(childTid, SCHED_RR, 0);
>      usleep(10000); 
>      // otherwise calling Active() immediately after Start() 
>      // causes a "pure virtual method called" error
>      }
>   return true; //XXX return value of pthread_create()???
> }
> 
> Usleep for ten seconds to avoid error looks a bit fragile. Could this be
> the problem?
> 
> Thanks for reading this far!
> Seppo
> 
> 
> 



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.