k4rthikr / unimrcp

Automatically exported from code.google.com/p/unimrcp
0 stars 0 forks source link

pollset field of mrcp_connection_agent_t might be accessed before it is initialized #49

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This causes acces violation exception to be thrown at the line 211 
(release 0.8,windows) of mrcp_client_connection.c:

if(apt_pollset_wakeup(agent->pollset) != TRUE) {

The following kind of logic will reproduce the problem:
1. create mrcp client (unimrcp_client_create)
2. create mrcp application (mrcp_application_create)
3. register mrcp application (mrcp_client_application_register)
4. start mrcp client (mrcp_client_start)
5. block thread until stack ready notification is received (on_ready)
6. when thread is unblocked create mrcp application session
7. create mrcp application channel
8. add channel to session

9. create "on_ready" handler which unblocks the thread waiting right after 
mrcp_client_start (see 5)

This problem happens because "on_ready" notification is sent when all the 
threads running child tasks of mrcp client are just created not when they 
are actually started and ready. 
So it is possible that when a channel is added to a session (which leads 
to invokation of "mrcp_client_control_message_signal" of 
"mrcp_client_connection.c") the thread which initializes "poolset" in 
"mrcp_client_agent_task_run" may still be running code which is above 
initialization i.e above this line:
agent->pollset = apt_pollset_create((apr_uint32_t)agent-
>max_connection_count,agent->pool);

As a temporary workaround I moved the pollset creation code from 
"mrcp_client_agent_task_run" to "mrcp_client_connection_agent_create". 
This helped and now there is no access violetion problems.

Original issue reported on code.google.com by aabaz...@gmail.com on 20 Oct 2009 at 6:48

GoogleCodeExporter commented 9 years ago
Thanks for the detailed description.
Looking at the code, I admit, the issue may happen.
Perhaps, this is not so critical, because usually client stack is initialized 
once on
application start-up, and only after certain amount of time application starts
processing calls.
Anyway, the issue MUST be fixed and I think on_ready event should be raised a 
bit
later, when client stack is fully initialized and indeed ready.

Original comment by achalo...@gmail.com on 20 Oct 2009 at 8:21

GoogleCodeExporter commented 9 years ago
Thank you, Arsen!

I understand that this issue is not critical in 95% of the applications, 
however it 
was quite critical for me. My mrcp client was not able to start in 95% of my 
attempts because of this problem.

Original comment by aabaz...@gmail.com on 20 Oct 2009 at 8:48

GoogleCodeExporter commented 9 years ago
I've had a closer look at the issue today.
Your temporary workaround indeed should work without an issue.
However from conceptual viewpoint, apt tasks should be able to raise 
start-complete
event, when they are indeed fully initialized and ready.
So I enhanced apt task a bit to achieve this goal.
Your issue should be fixed in r1208. Give it a try.

Original comment by achalo...@gmail.com on 21 Oct 2009 at 4:39

GoogleCodeExporter commented 9 years ago
Thank you Arsen! 

I've just checked the fix - everything works!

Original comment by aabaz...@gmail.com on 22 Oct 2009 at 5:29

GoogleCodeExporter commented 9 years ago

Original comment by achalo...@gmail.com on 9 Jan 2010 at 6:46