[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: Tue, 27 Nov 2007 15:52:13 +0300


Thank you for answers.

### 1 ###

[----- You wrote --------------------------------------------------

Indeed the temp SessionSet is not being reinitialised, thus during the 
session_set_copy, toggled fd from the recv result set may be put into the send 
result set...


Yes, I see the problem at the same mannere.

[----- You wrote --------------------------------------------------

By duplicating temp into temp1, temp2, temp3, you workaround the bug because 
probably your compiler initialise new stack variables with zeroee, which is not 
the case with all compilers, that's why I prefered solving the bug a bit 
differently by calling session_set_init(&temp) before each set computing. And 

of course it saves a bit of memory. The fix will be on cvs tonight, and in next 
release of course.


Khm... I have analized your solution...

I am unsure...

But I can't understand,

for what we must call session_set_init(&temp)

before each set computing?

If you'll look into the session_set_and() code, you'll

see, that variable "temp" is output argument of session_set_and().

So, we are not indeed to call session_set_init(&temp) in



if (recvs!=NULL){



    if (bits>0){


         /* copy the result set in the given user set */




In part below, we copy temp1 only if


it means, that function session_set_and(&temp1) 

was called before, and so, temp1 was initialisated.

(in cases of sends, errors - the same situation).


if (ret>0){

    if (recvs!=NULL)


    if (sends!=NULL)


    if (errors!=NULL)


    /* there are set file descriptors, return immediately */


    return ret;



May be I am wrong... Without looking on your 

version of "pesticide" I am unsure... Please, public

it on the forum.

### 2 ###

[----- You wrote --------------------------------------------------

- sched->time_: does not need locking. The risk is only that you may have a 
RtpSession not in a recv or send set and need to wait 10 ms more to have it. 

Not a big issue. Anyway changing the mutex_unlock would not fix it, since the 
rtp_session_recvm_with_ts() does not take this mutex to check the value of 


I am not sure, but:

I see, that variable sched->time_ is used in different

threads. And I don't want to be surprized by this potential 

thread-conflict... I think, that it is better to do something

with it, than do nothing. (It seems, that programm, which

is dependent of Moon phases, is not good :-)

It seems, you are right, that moving mutex

locking in sheduler is not enough solution... 


Serf Ma

reply via email to

[Prev in Thread] Current Thread [Next in Thread]