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 ?
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.
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 ?
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,
--
TQI - Technology and Quality on Information
| At.,
|
 |
| Technology
and Quality
on Information |
| Mauro Sérgio
Ferreira Brasil |
| Coordenador
de Projetos e
Analista de Sistemas |
| + [email protected] |
| : 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
--
TQI - Technology and Quality on Information
| At.,
|
 |
| Technology and Quality
on Information |
| Mauro Sérgio Ferreira Brasil |
| Coordenador de Projetos e
Analista de Sistemas |
| + [email protected] |
| : 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
