Hi Vadim!
Sorry...
Wrong terminology...
I mean, that I could notice this problem when I was debugging the
application...
I'll try to contact and make some search on "portaudio" library.
Regarding the patch you've sent me, I experienced a problem debugging
the application yesterday...
It seems the patch wasn't enough to avoid a crash on some scenario,
because the crash ocurred inside "__osip_find_transaction" on same
"udp.c" file like shown below:
/* TODO: fix it for IPv6 */
osip_message_fix_last_via_header (sipevent->sip,
inet_ntoa (((struct sockaddr_in *) & address)->sin_addr), ntohs
(((struct sockaddr_in *) & address)->sin_port)) ;
transaction = __osip_find_transaction (eXosip.j_osip,
sipevent, 1) ;
if (transaction != NULL)
This method calling occurs right after the first "if (!eXosip.j_osip)"
validation and before the second one (both present on your patch), and
at this point (on the moment of "__osip_find_transaction" method
calling) the "eXosip.j_osip" is NULL, what actually results on the
crash some methods invocations later.
I'll try to code the "transport_manager" methods blocking as I've
suggested on my first email (please see below), and get back to you
with a possible patch after some time of validation.
Thanks and best regards,
Mauro.
Vadim Lebedev escreveu:
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
--
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 |
|
