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.

Sign up for GitHub

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

Jump to bottom

avoid commands in 'g_assert' #2

Open
renegart opened this issue Aug 29, 2014 · 2 comments
Open

avoid commands in 'g_assert' #2

renegart opened this issue Aug 29, 2014 · 2 comments

Comments

@renegart
Copy link

I'm playing around with GstHarness since some days and had strange behaviours in 'gst_harness_teardown'. The Gstreamer framework complains about tear down running elements in playing state:

'Unexpected critical/warning:
Trying to dispose element queue0, but it is in PLAYING instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.'

After debugging a few hours I realised you try to set the state of the element in a 'g_assert' expression. This works only, if Gstreamer is compiled with 'G_DISABLE_ASSERT' not defined.
By default Gstreamer will be compiled with 'G_DISABLE_ASSERT' defined which causes that all 'g_assert' expressions are replaces by 'do { (void) 0; } while (0)' (see gtestutils.h)
This ends up in a not working GstHarness implementation. But it sould work regardless if 'G_DISABLE_ASSERT' is defined or not.

You should use 'g_assert' only for testing of an expression, but not for running commands as like as setting of element states.
@haaspors
Copy link
Contributor

Yes, you are correct. Interestingly enough I'm currently going over our code base and fixing these! I'll try to update our public repo also soon. Thanks!

@renegart
Copy link
Author

That would be great :)

havardgraff pushed a commit that referenced this issue May 6, 2016
@dv1 @sdroege
multiqueue: Recalculate fill level after changing high-threshold
a1d2f38 
This ensures the following special case is handled properly:

1. Queue is empty
2. Data is pushed, fill level is below the current high-threshold
3. high-threshold is set to a level that is below the current fill level

Since mq->percent wasn't being recalculated in step #3 properly, this
caused the multiqueue to switch off its buffering state when new data is
pushed in, and never post a 100% buffering message. The application will
have received a <100% buffering message from step #2, but will never see
100%.

Fix this by recalculating the current fill level percentage during
high-threshold property changes in the same manner as it is done when
use-buffering is modified.

https://bugzilla.gnome.org/show_bug.cgi?id=763757
havardgraff pushed a commit that referenced this issue Mar 31, 2022
@ystreet
discoverer: chain up to parent finalize methods in all our types
203e34f 
Fixes a memory leak:

Direct leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x5ac5cd in malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3
    #1 0x1007007 in g_malloc /work/glib-2.72.0/_builddir/../glib/gmem.c:125:13
    #2 0xf82e82 in g_data_set_internal /work/glib-2.72.0/_builddir/../glib/gdataset.c:464:8
    #3 0xf833f7 in g_datalist_id_set_data_full /work/glib-2.72.0/_builddir/../glib/gdataset.c:670:3
    #4 0xef81be in g_object_notify_queue_freeze /work/glib-2.72.0/_builddir/../gobject/gobject.c:295:7
    #5 0xef79c6 in g_object_unref /work/glib-2.72.0/_builddir/../gobject/gobject.c:3632:16
    #6 0x5e58bf in LLVMFuzzerTestOneInput /src/gstreamer/ci/fuzzing/gst-discoverer.c:132:5
    #7 0x4dd1a2 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    #8 0x4dc98a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
    #9 0x4de6c4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:809:5
    #10 0x4dea29 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:857:3
    #11 0x4ce4a0 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    #12 0x4f6f52 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #13 0x7f1c709980b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1984>
havardgraff pushed a commit that referenced this issue Sep 2, 2022
@ystreet
rtspconnection: protect cancellable by a mutex
598f2ab 
It is entirely possible for the cancellable to be cancelled (and freed)
in gst_rtsp_connection_flush() while there may be an ongoing read/write
operation.

Nothing prevents gst_rtsp_connection_flush() from waiting for the
outstanding read/writes.

This could lead to a crash like (where cancellable has been freed
within gst_rtsp_connection_flush()):

 #0  0x00007ffff4351096 in g_output_stream_writev (stream=stream@entry=0x7fff30002950, vectors=vectors@entry=0x7ffe2c6afa80, n_vectors=n_vectors@entry=3, bytes_written=bytes_written@entry=0x7ffe2c6af950,  cancellable=cancellable@entry=0x7fff300288a0, error=error@entry=0x7ffe2c6af958) at ../subprojects/glib/gio/goutputstream.c:377
 #1  0x00007ffff44b2c38 in writev_bytes (stream=0x7fff30002950, vectors=vectors@entry=0x7ffe2c6afa80, n_vectors=n_vectors@entry=3, bytes_written=bytes_written@entry=0x7ffe2c6afb90, block=block@entry=1, cancellable=0x7fff300288a0) at ../subprojects/gst-plugins-base/gst-libs/gst/rtsp/gstrtspconnection.c:1320
 #2  0x00007ffff44b583e in gst_rtsp_connection_send_messages_usec (conn=0x7fff30001370, messages=messages@entry=0x7ffe2c6afcc0, n_messages=n_messages@entry=1, timeout=timeout@entry=3000000) at ../subprojects/gst-plugins-base/gst-libs/gst/rtsp/gstrtspconnection.c:2056
 #3  0x00007ffff44d2669 in gst_rtsp_client_sink_connection_send_messages (sink=0x7fffac0192c0, timeout=3000000, n_messages=1, messages=0x7ffe2c6afcc0, conninfo=0x7fffac019610) at ../subprojects/gst-rtsp-server/gst/rtsp-sink/gstrtspclientsink.c:1929
 #4  gst_rtsp_client_sink_try_send (sink=sink@entry=0x7fffac0192c0, conninfo=conninfo@entry=0x7fffac019610, requests=requests@entry=0x7ffe2c6afcc0, n_requests=n_requests@entry=1, response=response@entry=0x0, code=code@entry=0x0) at ../subprojects/gst-rtsp-server/gst/rtsp-sink/gstrtspclientsink.c:2845
 #5  0x00007ffff44d3077 in do_send_data (buffer=0x7fff38075c60, channel=<optimized out>, context=0x7fffac042640) at ../subprojects/gst-rtsp-server/gst/rtsp-sink/gstrtspclientsink.c:3896
 #6  0x00007ffff4281cc6 in gst_rtsp_stream_transport_send_rtp (trans=trans@entry=0x7fff20061f80, buffer=<optimized out>) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream-transport.c:632
 #7  0x00007ffff4278e9b in push_data (stream=0x7fff40019bf0, is_rtp=<optimized out>, buffer_list=0x0, buffer=<optimized out>, trans=0x7fff20061f80) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2586
 #8  check_transport_backlog (stream=0x7fff40019bf0, trans=0x7fff20061f80) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2645
 #9  0x00007ffff42793b3 in send_tcp_message (idx=<optimized out>, stream=0x7fff40019bf0) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2741
 #10 send_func (stream=0x7fff40019bf0) at ../subprojects/gst-rtsp-server/gst/rtsp-server/rtsp-stream.c:2776
 #11 0x00007ffff7d59fad in g_thread_proxy (data=0x7fffbc062920) at ../subprojects/glib/glib/gthread.c:827
 #12 0x00007ffff7a8ce2d in start_thread () from /lib64/libc.so.6
 #13 0x00007ffff7b12620 in clone3 () from /lib64/libc.so.6

Fix by adding a cancellable lock and returning an extra reference used
across all read/write operations.  gst_rtsp_connection_flush() can free
the in-use cancellable and it will no longer affect any in progress
read/write.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2799>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@haaspors @renegart