Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault on gstreamer_sdp::SDPMessage::parse_buffer #108

Closed
maxmcd opened this issue May 30, 2018 · 8 comments
Closed

Segfault on gstreamer_sdp::SDPMessage::parse_buffer #108

maxmcd opened this issue May 30, 2018 · 8 comments

Comments

@maxmcd
Copy link
Contributor

maxmcd commented May 30, 2018

Example code:

let ret = gstreamer_sdp::SDPMessage::parse_buffer(b"t=0 0\r\n").unwrap();

Valgrind output:

==5178== Invalid read of size 4
==5178==    at 0x58E94D9: gst_sdp_message_emails_len (gstsdpmessage.c:897)
==5178==    by 0x58ED356: gst_sdp_message_as_text (gstsdpmessage.c:499)
==5178==    by 0x2D2920: gstreamer_sdp::sdp_message::SDPMessage::as_text (sdp_message.rs:134)
==5178==    by 0x19A9CA: <gst_rust::WsClient as ws::handler::Handler>::on_message (main.rs:239)
==5178==    by 0x146C75: <ws::connection::Connection<H>>::read_frames (connection.rs:658)
==5178==    by 0x150020: <ws::connection::Connection<H>>::read (connection.rs:602)
==5178==    by 0x16BECB: <ws::io::Handler<F>>::handle_event (io.rs:548)
==5178==    by 0x169A46: <ws::io::Handler<F>>::event_loop (io.rs:429)
==5178==    by 0x175502: <ws::io::Handler<F>>::run (io.rs:396)
==5178==    by 0x120042: <ws::WebSocket<F>>::run (lib.rs:331)
==5178==    by 0x11FC73: ws::connect (lib.rs:121)
==5178==    by 0x19ACA3: gst_rust::connect_to_websocket_server_async (main.rs:264)
==5178==  Address 0x8 is not stack'd, malloc'd or (recently) free'd

Digging into this a little bit more now, but hoping I might be missing something obvious.

I simplified the buffer value to hopefully provide a more concise failure example, but it also segfaults with a full SDP offer.

@maxmcd
Copy link
Contributor Author

maxmcd commented May 31, 2018

This works for me:

fn gst_sdp_message_parse_buffer(data: &[u8]) -> gstreamer_sdp::SDPMessage {
    unsafe {
        let mut sdp = mem::zeroed();
        gstreamer_sdp_sys::gst_sdp_message_new(&mut sdp);
        gstreamer_sdp_sys::gst_sdp_message_parse_buffer(
            data.to_glib_none().0 as *mut u8,
            data.len() as u32,
            sdp,
        );
        from_glib_full(sdp)
    }
}

@sdroege
Copy link
Owner

sdroege commented May 31, 2018

Good catch! A call to gst_sdp_message_init is needed here after the allocation, or as you do simply calling gst_sdp_message_new which does the same.
Exactly the same problem in parse_uri

Do you want to send a PR?

@maxmcd
Copy link
Contributor Author

maxmcd commented May 31, 2018

Yep!

On a somewhat related topic. SdpMessage isn't easily extractable from a WebRTCSessionDescription, I've had to resort too:

fn sdp_message_as_text(offer: gstreamer_webrtc::WebRTCSessionDescription) -> Option<String> {
    unsafe {
        from_glib_full(gstreamer_sdp_sys::gst_sdp_message_as_text(
            (*offer.to_glib_none().0).sdp,
        ))
    }
}

Should sdp be available as an attribute?

@sdroege
Copy link
Owner

sdroege commented May 31, 2018

Yes, there should be a getter for taking it from the struct field. I expect that there are more things missing for the webrtc and sdp library as nobody wrote an application with those in Rust yet, but all of them should be trivial to fix.

@sdroege
Copy link
Owner

sdroege commented May 31, 2018

There should also be a getter for the type field btw

@maxmcd
Copy link
Contributor Author

maxmcd commented May 31, 2018

Cool will likely tackle those in the coming days/weeks. Thanks for the help!

@maxmcd maxmcd closed this as completed May 31, 2018
@sdroege
Copy link
Owner

sdroege commented May 31, 2018

Let me know if you need some help or have any questions, I'd be happy to help with all this :)

@maxmcd
Copy link
Contributor Author

maxmcd commented May 31, 2018

Absolutely! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants