Hi,
upon testing of softdevice-cvs in combination with streamdev-cvs I got the the following errors which could be fixed by attached diffs.
error: undefined symbol: _ZN16cMenuWhatsOnItemC1EPK6cEventP8cChannelb fix: streamdev-cvs-client.diff + streamdev-cvs-Makefile.diff
error: streamdev-cvs server "pure virtual method called" fix: streamdev-cvs-server.diff
pending bug: server does not switch channel upon client request. only channels from current (server side) transponder could be selected.
test enviroment: vdr-1.3.22 (unpatched, vanilla), softdevice-cvs (from today, xv-out)
Am Sonntag, 6. März 2005 12:55 schrieb Stefan Lucke:
Probably these two work together. Your patch doesn't really fix this issue (which btw. doesn't happen with gcc 2.95) because still only the base method is called (which does nothing now instead of throwing the pure virtual error) and not, as it should, the derived method.
I assume this is a compiler bug, since the error should be caught at compile-time (I can't see any error though, since the called object is a derivation and the method is derived, too). Anyway, if I "shift around" those methods a bit, it throws a "pure virtual method" error with gcc 2.95, but not with gcc 3.x.
Greetings, Sascha
On Sonntag, 6. März 2005 14:25, Sascha Volkenandt wrote:
Setting suspend mode from "offer" to "always" fixed that. Whithout server output device, I need to place: streamdev-server.SuspendMode = 1 in setup.conf.
As cStreamdevStreamer is derived from cThread which in term has no Detach() Attach() methods, cStreamdevServer should provide those methods. Yes maybe thats a compiler issue. gcc --version gcc (GCC) 3.3.1 (SuSE Linux)
Sascha Volkenandt wrote:
I've seen pure virtual method errors before with cThread's. There is a way how these pure virtuals can get active: At destructor time, as soon as the derived class is destructed, the virtuals get reverted to the pure virtuals of the base class, before the base class destructor takes over. Reason is that the derived object is gone as soon as the derived destructor ends, and only the base object needs to destruct.
In this case (just a guess by a quick look at source code): ~cStreamdevStreamer() calls Stop(), and Stop() calls Detach(). Since the derived cStreamdevLiveStreamer is already destructed, its virtual Detach() is gone too, and the pure virtual cStreamdevStreamer::Detach() gets called.
Virtuals in destructors are dangerous. Better make sure the thread is stopped before the object destructs...
Cheers,
Udo
On Sonntag, 6. März 2005 17:37, Udo Richter wrote:
That's exact that was I've seen when I run vdr from gdb. The line reported was line 103 from streamer.c : Detach ().
Virtuals in destructors are dangerous. Better make sure the thread is stopped before the object destructs...