fernpass / unimrcp

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

MRCPv1 500 internal server error response to SETUP causes crash #124

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1.
2.
3.

Please use labels and text to provide additional information.
(gdb) bt full
#0  0x0000003c80808950 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#1  0x00002b9297ef1eff in apr_pool_destroy (pool=0x1979f098) at 
memory/unix/apr_pools.c:320
        active = (apr_memnode_t *) 0x1979f070
        allocator = (apr_allocator_t *) 0x196ef2d0
#2  0x00002aaab239a3d9 in rtsp_client_connection_destroy 
(rtsp_connection=0x1979f160) at src/rtsp_client.c:416
        client = (rtsp_client_t *) 0x2aaaac02ab10
        pollset = (apt_pollset_t *) 0x2aaaac02abb8
#3  0x00002aaab239a4ea in rtsp_client_task_msg_process (task=<value optimized 
out>, task_msg=<value optimized out>) at src/rtsp_client.c:482
        client = (rtsp_client_t *) 0x2aaaac02ab10
        data = <value optimized out>
#4  0x00002aaab236eaeb in apt_task_msg_process (task=0x2aaaac02f838, 
msg=0x196ef350) at src/apt_task.c:285
        status = 0
#5  0x00002aaab236bdbc in apt_poller_task_run (base=<value optimized out>) at 
src/apt_poller_task.c:181
        running = (apt_bool_t *) 0x2aaaac02f8e8
        status = <value optimized out>
        num = 1
        ret_pfd = (const apr_pollfd_t *) 0x2aaaac02ea48
        timeout = -1
        queue_timeout = 0
        time_now = <value optimized out>
        time_last = 0
        i = 0
        task_name = 0x2aaaac02a9d8 "mrcpbad"
#6  0x00002aaab236ed04 in apt_task_run (thread_handle=0x2aaaac02fcb8, 
data=<value optimized out>) at src/apt_task.c:481
        task = (apt_task_t *) 0x2aaaac02f838
#7  0x0000003c808064a7 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#8  0x0000003c7fcd3c2d in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb)

Original issue reported on code.google.com by cmrie...@gmail.com on 22 Jun 2011 at 1:27

GoogleCodeExporter commented 8 years ago
Trace log attached.  Looks like the RTSP connection gets destroyed twice.

Original comment by cmrie...@gmail.com on 22 Jun 2011 at 1:30

Attachments:

GoogleCodeExporter commented 8 years ago
I found that if the server leaves the connection open after sending the 500 
response, there is no crash.  If the server closes the connection immediately 
after sending the 500 response, the client crashes.

Original comment by cmrie...@gmail.com on 22 Jun 2011 at 2:48

GoogleCodeExporter commented 8 years ago
For now, I commented out the rtsp_client_connection_destroy() call in 
rtsp_client_on_disconnect().  Hopefully I won't leak memory.

Original comment by cmrie...@gmail.com on 22 Jun 2011 at 3:41

GoogleCodeExporter commented 8 years ago
The change looks ok, so far in production.  I'm reading through the UniMRCP 
source code for RTSP/MRCPv1 to learn how it all works.  I guess I'll start 
committing changes once I fully understand the code, unless Arsen has any 
objections.

Original comment by cmrie...@gmail.com on 23 Jun 2011 at 6:02

GoogleCodeExporter commented 8 years ago
Hi Chris,

You're right the RTSP connection is destroyed twice, and this unfortunately but 
unavoidably leads to the client crash. Anyway, it looks like a leftover from 
r1400 (Issue-60). I should have removed the call for 
rtsp_client_connection_destroy() from rtsp_client_on_disconnect(), as you 
suggested. There shouldn't be any drawbacks.

Fixed in r1809.

Thanks.

Original comment by achalo...@gmail.com on 21 Jul 2011 at 2:03