Mauro Sergio Ferreira Brasil wrote: > Hi Vadim! > > Sorry by the late answer, but we were very busy here with some extemely > urgent > demands. > > Your patch worked pretty fine, and I thank you very much! > I have just shifted up the first "eXosip.j_osip" validation before the > "osip_malloc" calling, so the allocation don't need to be undone. > > I'm a litle curious... > Is this patch applied on trunk ? >
Yes it is in the trunk now... > Now I'm experiencing a crash on "NonAdaptingProcess" method of "pa_process.c" > file from "portaudio" library on call termination, but only when I'm on a > depuration session. > > "depuration"? What do you mean? > It seems that the audio processing thread is not being terminated as fast as > required on this scenario and the "wait" routines make some "guessing > callculation" to find out how much time the main thread will wait. (see the > comment got from the codes that is below). > > /* Calculate timeOut longer than longest time it could take to return > all buffers. */ > timeout = (int)(stream->allBuffersDurationMs * 1.5); > if( timeout < PA_MME_MIN_TIMEOUT_MSEC_ ) > timeout = PA_MME_MIN_TIMEOUT_MSEC_; > > The problem is that sometimes (not always) when I'm depurating the code, the > application crashes because of that. > > I was wondering why the "WaitForSingleObject" present on method "StopStream" > of > file "pa_win_wmme.c" is not configured to INFINITE what will result on the > main > thread waiting the worker thread as long as it needs to finish. > Is there any possibility of this worker thread not return or take too long to > do > it ? Thats why the INFINITE is not used there ? > > I don't really know. Yous should ask PortAudio developpers.. You can also try and use PortAudio DirectSound backend... Or try to put INFINITE in WaitForSngleObject Thanks Vadim > Thanks and best regards, > Mauro. > > > > > Vadim Lebedev escreveu: > > Mauro, > > > > Please try attached patch > > > > Thanks > > Vadim > > Mauro Sergio Ferreira Brasil wrote: > >> Hello there! > >> > >> We provide support to an Windows application that uses OpenWengo (version > >> 2.1) libraries as VoIP infraestructure, and I'm migrating the libs to > >> updated > >> QuteCom version 2.2-RC3. > >> > >> On first tests with normal condition (SIP and RTP via UDP transport) I've > >> made a call and right after finishing it I tried to close the application. > >> The application crashed with the following callstacks (these two seems to > >> be > >> the main involved on the crash): > >> > >> UOLFoneClientd-1.0.0.22.dll!pthread_mutex_destroy(pthread_mutex_t_ * > >> * > >> mutex=0x05227764) Line 92 + 0xc bytes C > >> UOLFoneClientd-1.0.0.22.dll!owqueue_free(OWQueue * queue=0x05227720) > >> Line 199 + 0xc bytes C > >> UOLFoneClientd-1.0.0.22.dll!owsl_socket_info_free(OWSLSocketInfo * > >> socket=0x05227598) Line 203 + 0xc bytes C > >> UOLFoneClientd-1.0.0.22.dll!owsl_tls_close(OWSLSocketInfo * > >> socket=0x05227598) Line 623 + 0x9 bytes C > >> UOLFoneClientd-1.0.0.22.dll!owsl_close(int socket=3) Line 447 + 0xf > >> bytes C > >> UOLFoneClientd-1.0.0.22.dll!transport_socket_free(int * > >> socket=0x05227550) Line 220 + 0xb bytes C > >> UOLFoneClientd-1.0.0.22.dll!owlist_free_all(OWList * list=0x0521d188, > >> void (void *)* free_element=0x08cf3330) Line 99 + 0x7 bytes C > >> > UOLFoneClientd-1.0.0.22.dll!transport_terminate() Line 319 + 0x10 > >> bytes C > >> UOLFoneClientd-1.0.0.22.dll!eXosip_quit() Line 367 C > >> UOLFoneClientd-1.0.0.22.dll!phTerminate() Line 2583 C > >> UOLFoneClientd-1.0.0.22.dll!owplShutdown() Line 374 C > >> UOLFoneClientd-1.0.0.22.dll!CPhApiAdapter::Finalize() Line 463 C++ > >> > >> This first one is regarding the application's thread on which I called the > >> termination method. > >> > >> > UOLFoneClientd-1.0.0.22.dll!osip_list_add(osip_list * li=0x0000001c, > >> void * el=0x0523efd0, int pos=-1) Line 104 + 0x3 bytes C > >> UOLFoneClientd-1.0.0.22.dll!__osip_add_nist(osip * osip=0x00000000, > >> osip_transaction * nist=0x0523efd0) Line 598 + 0x12 bytes C > >> UOLFoneClientd-1.0.0.22.dll!osip_transaction_init(osip_transaction * > >> * > >> transaction=0x0904fc18, osip_fsm_type_t ctx_type=NIST, osip * > >> osip=0x00000000, osip_message * request=0x05249b38) Line 212 + 0xf bytes > >> C > >> UOLFoneClientd-1.0.0.22.dll!eXosip_process_newrequest(osip_event * > >> evt=0x051f6398) Line 1882 + 0x1b bytes C > >> UOLFoneClientd-1.0.0.22.dll!eXosip_recv(int socket=1) Line 2541 + > >> 0xc > >> bytes C > >> UOLFoneClientd-1.0.0.22.dll!transport_on_data_socket_event(int > >> socket=1, > >> OWSLEvent event=OWSL_EVENT_READ, void * user_data=0x00000000) Line 800 + > >> 0xa > >> bytes C > >> UOLFoneClientd-1.0.0.22.dll!owsl_asynchronous_loop(void * > >> dummy=0x00000000) Line 130 + 0x19 bytes C > >> UOLFoneClientd-1.0.0.22.dll!ptw32_threadStart(void * > >> vthreadParms=0x0521b2d0) Line 219 + 0x9 bytes C > >> > >> The crash occurred on top method of this second thread that is the one > >> responsible for handling the primitives received from the network. > >> > >> I've searched blocking conditions in order to prevent such situation but I > >> was not successfull. So I was thinking to suggest some blocking (critical > >> section protected by some sort of mutex) procedure on file > >> "transport_manager.c" with two objectives: > >> > >> 1- block "transport_terminate()" execution while an event is being > >> handled; and, > >> 2- set a finalization flag that must be validated by > >> "transport_on_data_socket_event", as well as "callback methods" like it, > >> to > >> avoid their execution after transport termination. > >> > >> Can you guys send me your general impression of this ? > >> > >> Thanks and best regards, > >> > >> -- > >> __At., > >> > >> _ > >> > >> *Technology and Quality on Information* > >> Mauro Sérgio Ferreira Brasil > >> Coordenador de Projetos e Analista de Sistemas > >> + [email protected] <mailto:@tqi.com.br> > >> : www.tqi.com.br <http://www.tqi.com.br> > >> ( + 55 (34)3291-1700 > >> ( + 55 (34)9971-2572 > >> > >> -------------------------------------------------------------------------------- > >> > >> _______________________________________________ > >> QuteCom-dev mailing list > >> [email protected] > >> http://lists.qutecom.org/mailman/listinfo/qutecom-dev > >> > > > > -- > __At., > > _ > > *Technology and Quality on Information* > Mauro Sérgio Ferreira Brasil > Coordenador de Projetos e Analista de Sistemas > + [email protected] <mailto:@tqi.com.br> > : www.tqi.com.br <http://www.tqi.com.br> > ( + 55 (34)3291-1700 > ( + 55 (34)9971-2572 > > _______________________________________________ QuteCom-dev mailing list [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
