[Kwintv] crash in QtVision::SetChannel

[Dawit A.]

> As you maybe already know, there is a bug in QtVision::SetChannel causing=
 a
> crash sometimes.

What do you mean sometimes ?  It should only happen whenever openChannel is=
=20
called, right ?

> A backtrace showed the line 505 in qtvision.cpp to have caused the crash.
> And indeed:
> void QtVision::setChannel( Channel *channel )
> {
>     if (!channel)
>         return;
>
>     //kdDebug() << "QtVision::setChannel()" << endl;
> =B7=B7=B7=B7
>     if (_chan)
>       _prevChannel =3D _chan->number (); // line 505
>
> It assumes, that if _chan is not NULL then it is a valid pointer. Which is
> not a valid assumption, since the channels are deleted by ChannelStore (a=
nd
> in my case they were deleted by openChannelFile)

Well actually this is not a bug in ::setChannel.  Though it shows up at thi=
s=20
point.  It is rather a bug in ::openChannelFile (const QString&) where=20
_cs->clear() is called without the local pointer to a Channel object being=
=20
reset.  This, as you ponited out, leaves a dangling pointer to a channel=20
object.  But all the code in QtVision assumes on proper intialization of _c=
s. =20
It just happens that none of them are currently called before setChannel is.

> I see some possible solutions to this:
> 1) remove this previous channel thing - it is only used for dcop if I
> understand it correctly, and I dont see for what it is good for

No, do not do that.  It is very simple to fix this problem.  FWIW, the=20
_prevChannel is a feature that allows you to go back to the previous=20
channel by pressing one configurable shortcut key.  By default this is=20
Key_L.  This is the same feature available on many TV sets/Remote=20
controls as go back, Last, recall, previous etc...

> 3) take care to do '_chan =3D NULL' when the channel store is deleted (or
> that exact channel is deleted) -- this may be impossible

And why is this impossible ? Channel is a QObject.  All one has to do is=20
connect to its destroyed signal and reset the local pointer accordingly. =20
Actually, there isn't even a need for that right now even though it is the=
=20
most proper fix. The easiest thing to do for the current situtation would b=
e=20
to simply null out the _ch pointer whenever _cs->clear() is called.

> I vote for solution 1)
>
> What do you vote for? :)

I vote for item #4.  Let Dawit fix it since he caused the problem to begin=
=20
with. :)

Regards,
Dawit A.