[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [Linphone-developers] Bug and bug-pesticide in session_set_selec
From: |
Машкин С В |
Subject: |
Re: Re: [Linphone-developers] Bug and bug-pesticide in session_set_select() of oRTP-0.13.1 (multi-duplex-rtp-sessions problem) |
Date: |
Mon, 17 Dec 2007 12:57:46 +0300 |
Hi, Simon!
> >
> > Heart of session_set_select() bug, I've found, is that
> >
> > sends-event-information OVERWRITES recvs-event-information
> >
> > (if sends arised),
> >
> > and errors-event-information OVERWRITES recvs-event-information
> >
> > (if errors arised).
>
> How can this be possible ?
> Normally the sessionsets are large enough to contain the maximum number of
> session allowed. How many sessions do you use simultaneously ?
Sorry, if my description of the bug was not understandable...
May be "OVERWRITES" was not correct word...
(Now, one week after, I saw, that I wrote abracadabra
instead of really clear description of "bug heart" =( Sorry.
Now I'll try to explain the heart of the bug more clearly (I hope =).
---------------------------------------------------------------------
As I wrote before,
> The heart of the bug is (As it seems to me):
>
> when function session_set_select() is used, it must
> 1.return total number of rcv+send+error events
> 2.reset setted bits in sched->w_sessions,
> sched->r_sessions sets
> 3.set/reset bits in recvs,sends,errors sets
>
> but current version (oRTP ver 0.13.1) of
> session_set_select does not correctly work with
> 3.set/reset bits in recvs,sends,errors sets
As I can see,
[3.set/reset bits in recvs,sends,errors sets]
is devided into two steps:
A)
session_set_and() makes
[3.set/reset bits in recvs,sends,errors sets]
but writes the results only to [temp] variable.
B)
session_set_copy()
copy these results from [temp] to [recvs],[sends]or[errors].
BUT:
if session_set_and() returns zero (for example for recvs, recvs!=NULL)
step B) has no place (for recvs),
if session_set_and() returns nonzero (for example for sends, sends!=NULL)
step B) has place (for sends),
so, operation [3.set/reset bits in recvs,sends,errors sets]
is not finished for recvs, but finished for sends.
As my experiments shown, this incomplete operation
with [3.set/reset bits in recvs,sends,errors sets]
leads to the descripted bug.
That's all...
P.S.: Sorry, again, for incorrect description in the 2nd message.
Hope, the 3rd is correct and more understandable.
Thanks,
Serg Ma.