GNOME Bugzilla – Bug 439255
[rtspsrc] crash on unsupported transport
Last modified: 2007-05-18 13:28:17 UTC
Version: 2.19.0 What were you doing when the application crashed? Trying to listen to audio stream from my local public radio station. URL is: rtsp://129.186.60.6:554/encoder/woi-am.rm Distribution: Fedora Core release 6 (Zod) Gnome Release: 2.16.3 2007-01-31 (Red Hat, Inc) BugBuddy Version: 2.16.0 System: Linux 2.6.20-1.2948.fc6 #1 SMP Fri Apr 27 19:48:40 EDT 2007 i686 X Vendor: The X.Org Foundation X Vendor Release: 70101000 Selinux: No Accessibility: Disabled Memory status: size: 112062464 vsize: 0 resident: 112062464 share: 0 rss: 24809472 rss_rlim: 0 CPU usage: start_time: 1179427194 rtime: 0 utime: 74 stime: 0 cutime:69 cstime: 0 timeout: 5 it_real_value: 0 frequency: 29 Backtrace was generated from '/usr/bin/totem' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1209095760 (LWP 9622)] [New Thread -1254925424 (LWP 9624)] 0x00c17402 in __kernel_vsyscall ()
+ Trace 134692
Thread 1 (Thread -1209095760 (LWP 9622))
----------- .xsession-errors (208 sec old) --------------------- (evolution:3904): camel-WARNING **: camel_exception_get_id called with NULL parameter. (evolution:3904): camel-WARNING **: camel_exception_get_id called with NULL parameter. (evolution:3904): camel-WARNING **: camel_exception_get_id called with NULL parameter. (evolution:3904): camel-WARNING **: camel_exception_get_id called with NULL parameter. (evolution:3904): camel-WARNING **: camel_exception_get_id called with NULL parameter. (evolution:3904): camel-WARNING **: camel_exception_get_id called with NULL parameter. (evolution:3904): camel-WARNING **: camel_exception_get_id called with NULL parameter. (evolution:3904): camel-WARNING **: camel_exception_get_id called with NULL parameter. --------------------------------------------------
Compiled latest version of totem from SVN and got a similar crash.
It's a crash in the RTSP plugin of GStreamer.
Can reproduce. The bug still exists in GStreamer CVS. I know what the problem is, but I'm not entirely sure about the supposed logic of the code, so I'll better let Wim fix it. In gst-plugins-good/gst/rtsp/gstrtspsrc.c, gst_rtspsrc_setup_streams(): switch (code) { case RTSP_STS_OK: break; case RTSP_STS_UNSUPPORTED_TRANSPORT: /* cleanup of leftover transport */ gst_rtspsrc_stream_free_udp (stream); goto next_stream; default: goto send_error; } /* parse response transport */ { RTSPTransport transport = { 0 }; ... next_stream: /* clean up our transport struct */ rtsp_transport_init (&transport); } } The 'goto next_stream' from the switch jumps directly into the parse block, where it'll try to clear the transport variable. However, because of the goto statement the transport variable has either not been cleared or not been allocated on the stack in the first place, so rtsp_transport_init() will try to free a garbage pointer when doing g_free(transport->foobar). Also, I'm wondering if in the if() construction above next_stream there's a jump/continue/something missing.
* gst/rtsp/gstrtspsrc.c: (gst_rtspsrc_setup_streams): Don't crash when an unsupported transport error was returned by the server, just try to configure the next stream. Fixes #439255.