GNOME Bugzilla – Bug 756818
rtspsrc under Windows: invalid pointer address in attempting to use a pointer argument in a call
Last modified: 2018-03-08 17:59:06 UTC
This seems like a repeat of older bugs (706588) so my apologies in advance if there's something obvious that I'm missing. I have constructed the following pipeline to pull an RTSP stream from a camera: rtspsrc location=rtsp://foo:bar@192.168.105.84/Streaming/Channels/2 ! fakesink This pipeline works fine under Linux, but under Windows I receive the following: WARNING: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSink:udpsink0: Error sending UDP packets Additional debug info: gstmultiudpsink.c(722): gst_multiudpsink_send_messages (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSink:udpsink0: client 192.168.105.84:8222, reason: Error sending message: The system detected an invalid pointer address in attempting to use a pointer argument in a call. The workaround for this in the past was to set force-ipv4=true, but it seems that that flag is now deprecated. Any ideas on how I should proceed? Please let me know what additional information you require to help debug this. Thanks!
Maybe by using g_new0 instead of g_new for allocating the messages it might work better... but it really shouldn't. Can you check if all the GstOutputMessage and GOutputVector in the code there contain something sensible?
As we expected, g_new0 doesn't change the behavior. Could you please offer some guidance as to what I'm looking for in GstOutputMessage and GOutputVector? I've inspected the message that we're sending and the vector and they both appear to have seemingly sane values for their fields.
It might also be that the parameters passed to sendmmsg() or similar in g_socket_send_messages() are not properly initialized. It might also be related to the "ABI is incompatible" comment in there, maybe it works if we always copy. Basically you'll have to check if we populate the messages/vectors properly, and if GLib is then passing this to the socket correctly. Like if the translation to the system types is correct, see above.
An update on this: After picking through things I found that the pipeline was attempting to send messages to an IPv4 address over an IPv6 socket, which is apparently not allowed with the sockets used in Windows? Perhaps there is some additional configuration or flags that can help out here....potentially setting IPV6_V6ONLY to false when creating the socket if we aren't already? Regardless, I was able to work around this issue by altering my source camera's network settings so it's up and rolling. An additional thing to consider is that it may be beneficial to add some logging in gst_multiudpsink_configure_client to put out some error logging if the address is an IPv4 family address and the available socket is not compatible. Thoughts? This is low hanging fruit, so I can give you a quick patch for this if you would like.
Hm! It should create a v6 socket for v6 clients, and a v4 socket for v4 clients.
Can you send a debug log with GST_DEBUG=6 of the problem? We use the socket created by udpsrc for multiudpsink here, and the socket created by udpsrc is created for udp://IP:PORT. And udpsrc should've created an IPv6 socket as it creates a socket for the address family of the address.
Hm but the udpsrc is actually generated for > if (stream->is_ipv6) > host = "udp://[::0]"; > else > host = "udp://0.0.0.0"; Where is_ipv6 is based on the address type in the RTSP messages. For your server, what are all the RTSP messages that are exchanged? Is there an IN4 connection in the SDP that has an IPv6 address?
Not sure what to do with this, no further information was supplied, and also it's been quite some time so it might have been fixed in the meantime. Closing for now, please re-open or file a new bug if the problem still happens with recent versions of GStreamer (1.12.x or ideally 1.13.x/1.14), thanks!