I need help.... This is why sometimes hangs after my patch... On ProvidesChannel I delete the cDvbDevice and i make it again. In that few nanoseconds someone try to access the structure deleted without waiting for proper allocation of new one. How to wait ultil all needed thread are ready? Best regards, Eddi ==4215== Thread 1: ==4215== Syscall param ioctl(arg) contains uninitialised byte(s) ==4215== at 0x4000792: (within /lib/ld-2.3.6.so) ==4215== by 0x8094782: cDevice::DelPid(int, cDevice::ePidType) (device.c:491) ==4215== by 0x8094888: cDevice::Detach(cReceiver*) (device.c:1297) ==4215== by 0x80CEC7B: cReceiver::Detach() (receiver.c:58) ==4215== by 0x80FAE0B: cTransfer::~cTransfer() (transfer.c:27) ==4215== by 0x80FACBA: cTransferControl::~cTransferControl() (transfer.c:123) ==4215== by 0x80CC349: cControl::Shutdown() (player.c:94) ==4215== by 0x8094B9F: cDevice::SetChannel(cChannel const*, bool) (device.c:621) ==4215== by 0x8094E1A: cDevice::SwitchChannel(cChannel const*, bool) (device.c:576) ==4215== by 0x8085E0D: cChannels::SwitchTo(int) (channels.c:1024) ==4215== by 0x80AE950: cDisplayChannel::ProcessKey(eKeys) (menu.c:3343) ==4215== by 0x80FD167: main (vdr.c:1052) ==4215== Warning: noted but unhandled ioctl 0x6F2A with no size/direction hints ==4215== This could cause spurious value errors to appear. ==4215== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==4215== Warning: noted but unhandled ioctl 0x6F2A with no size/direction hints ==4215== This could cause spurious value errors to appear. ==4215== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==4215== Warning: invalid file descriptor -1 in syscall close() ==4215== Warning: invalid file descriptor -1 in syscall close() ==4215== Warning: invalid file descriptor -1 in syscall close() ==4215== Warning: noted but unhandled ioctl 0x6F43 with no size/direction hints ==4215== This could cause spurious value errors to appear. ==4215== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==4215== ==4215== Invalid read of size 1 ==4215== at 0x401D248: strlen (mc_replace_strmem.c:246) ==4215== by 0x41B9FD4: vfprintf (in /lib/tls/i686/cmov/libc-2.3.6.so) ==4215== by 0x424256D: vsyslog (in /lib/tls/i686/cmov/libc-2.3.6.so) ==4215== by 0x80F9082: syslog_with_tid(int, char const*, ...) (tools.c:41) ==4215== by 0x809ADA7: cDvbDevice::ProvidesChannel(cChannel const*, int, bool*) const (dvbdevice.c:828) ==4215== by 0x8093330: cDevice::GetDevice(cChannel const*, int, bool*) (device.c:300) ==4215== by 0x8094BEC: cDevice::SetChannel(cChannel const*, bool) (device.c:638) ==4215== by 0x8094E1A: cDevice::SwitchChannel(cChannel const*, bool) (device.c:576) ==4215== by 0x8085E0D: cChannels::SwitchTo(int) (channels.c:1024) ==4215== by 0x80AE950: cDisplayChannel::ProcessKey(eKeys) (menu.c:3343) ==4215== by 0x80FD167: main (vdr.c:1052) ==4215== Address 0x1 is not stack'd, malloc'd or (recently) free'd ==4215== ==4215== Process terminating with default action of signal 11 (SIGSEGV) ==4215== Access not within mapped region at address 0x1 ==4215== at 0x401D248: strlen (mc_replace_strmem.c:246) ==4215== by 0x41B9FD4: vfprintf (in /lib/tls/i686/cmov/libc-2.3.6.so) ==4215== by 0x424256D: vsyslog (in /lib/tls/i686/cmov/libc-2.3.6.so) ==4215== by 0x80F9082: syslog_with_tid(int, char const*, ...) (tools.c:41) ==4215== by 0x809ADA7: cDvbDevice::ProvidesChannel(cChannel const*, int, bool*) const (dvbdevice.c:828) ==4215== by 0x8093330: cDevice::GetDevice(cChannel const*, int, bool*) (device.c:300) ==4215== by 0x8094BEC: cDevice::SetChannel(cChannel const*, bool) (device.c:638) ==4215== by 0x8094E1A: cDevice::SwitchChannel(cChannel const*, bool) (device.c:576) ==4215== by 0x8085E0D: cChannels::SwitchTo(int) (channels.c:1024) ==4215== by 0x80AE950: cDisplayChannel::ProcessKey(eKeys) (menu.c:3343) ==4215== by 0x80FD167: main (vdr.c:1052) ==4215== > -----Messaggio originale----- > Da: vdr-bounces@xxxxxxxxxxx [mailto:vdr-bounces@xxxxxxxxxxx] Per conto di > Eddi > Inviato: gioved? 8 febbraio 2007 1.22 > A: 'VDR Mailing List' > Oggetto: [PATCH] R: R: VDR & Multiple frontends > > The patch is ready and available as attachment to this mail and at > > http://tux.dpeddi.com/lr319sta/downloads/vdr_1.4.5_eddi-multiple- > frontend.pa > tch > > Card detection should work in all environment, and the patch should be > transparent in environment with adapters that have a single tuner or > adapter > that provide a bus for each tuner. In this case the frontend appear as a > VDR > device. > > At the moment, sometime channel change works and sometime fails, I suppose > is due to the time thread needs to close. > > Can someone do a regression test with my patch applied? > > I need help to solve this? I have to use valgring? > > Best Regards, > > Eddi > > > > > -----Messaggio originale----- > > Da: vdr-bounces@xxxxxxxxxxx [mailto:vdr-bounces@xxxxxxxxxxx] Per conto > di > > Eddi > > Inviato: gioved? 8 febbraio 2007 0.34 > > A: 'VDR Mailing List' > > Oggetto: R: R: VDR & Multiple frontends > > > > Since I don't get any news you, I'm working on implementing this. > > > > I had to modify these files: > > device.c device.h dvbdevice.c dvbdevice.h > > > > At the moment I don't get any image yet from second frontend yet, but > > changing channel I get EPG from second tuner. > > > > I hope in the next day sto submit a patch > > > > Best Regards, > > > > Eddi > > > > > > > > > -----Messaggio originale----- > > > Da: vdr-bounces@xxxxxxxxxxx [mailto:vdr-bounces@xxxxxxxxxxx] Per conto > > di > > > Klaus Schmidinger > > > Inviato: domenica 10 dicembre 2006 11.14 > > > A: vdr@xxxxxxxxxxx > > > Oggetto: Re: R: VDR & Multiple frontends > > > > > > Eddi wrote: > > > >> Eddi wrote: > > > >>> Hi, > > > >>> > > > >>> I wrote a patch to Steve Toth hvr3000 repository, so my FlyDVB > Trio > > > can > > > >>> use multiple frontend. > > > >>> > > > >>> The bus of the two frontend is shared, isn't possible to get > access > > to > > > >>> both frontend simultaneously, so I get an -EBUSY error by trying > > > >>> accessing frontend1 if frontend0 is in use. > > > >>> > > > >>> VDR doesn't support yet the second frontend, and it try to get > > > exclusive > > > >>> access on both frontend on start, so the second frontend is > > inusabile. > > > >>> > > > >>> Vdr should probe for multiple frontend at start, and access > frontend > > > >>> only on channel change. > > > >> Wouldn't it be better to hide this deficiency in the driver? > > > >> Klaus > > > > > > > > Actually it seems that on Hybrid card is and will be quite common > that > > > > multiple frontend share a single bus. > > > > > > > > Linuxtv API tell that a driver may offer frontendN nodes > > > > www.linuxtv.org/download/linux-dvb-api-1.0.0.pdf > > > > that vdr don't support > > > > > > > > I think is impossibile, to solve by driver, since switching between > > > frontend > > > > happened by opening the frontend/demux device. > > > > > > > > VDR try access to frontend on start (actually it doesn't start > > multiple > > > fe > > > > on same adapter, so I solved with symlink), and open all the > frontend. > > > > > > > > If open fails it refuse to use the frontend. If open with success, > it > > > start > > > > N thread as many as the number of adapter/frontend. > > > > > > > > I don't understand what you mean for deficiency, if you mean the > > EBUSY, > > > yes > > > > I could remove it, but it doesn't solve since with two tread open I > > > should > > > > get a ping-pong between the two frontend so I can't get any image. > > > > > > > > If you mean for deficiency the two frontend on the same adapter, is > > > > logically correct, and is a deficiency that vdr doesn't supporti t. > > > > > > > > Since I like VDR, I'd like it support this. > > > > > > I've gone through the LinuxDVB API description regarding the frontend > > > again and apparently it is documented that multiple frontends on the > > same > > > adapter can't be open in read/write mode at the same time (so the > > > "deficiency" > > > is actually on VDR's side ;-). > > > > > > Well, so VDR could open them in read-only mode first and switch one of > > > them > > > to read/write mode shortly whenever it does a tuning operation, and go > > > back > > > to read-only after that. It would also have to switch to read/write > > > shortly > > > whenever it reads a frontend event with ioctl(FE_GET_EVENT). With such > > > modifications > > > it should be possible to make VDR support a multiple frontend adapter. > > > In order to set up the necessary VDR devices, cDvbDevice::Initialize() > > > would also have to be enhanced to probe for multiple frontends > > > on the same adapter. > > > > > > Klaus > > > > > > _______________________________________________ > > > vdr mailing list > > > vdr@xxxxxxxxxxx > > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > > > > _______________________________________________ > > vdr mailing list > > vdr@xxxxxxxxxxx > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
