g_assert in production code?

[Ben Rush]

Yeah, so the reason I was asking about the nature g_assert being compiled
out is the following from the documentation:

https://developer.gnome.org/glib/stable/glib-Testing.html#g-assert

The macro can be turned off in final releases of code by defining
G_DISABLE_ASSERT when compiling the application, so code must not depend on
any side effects from expr . Similarly, it must not be used in unit tests,
otherwise the unit tests will be ineffective if compiled with
G_DISABLE_ASSERT. Use g_assert_true()
<https://developer.gnome.org/glib/stable/glib-Testing.html#g-assert-true> and
related macros in unit tests instead.

I knew that compiling it out was something that could be done, and I just
wanted to make sure that the code I was using was indeed built as it was
intended. I'll try updating and see if it goes away. Thanks.


On Tue, Oct 1, 2019 at 2:11 PM Sebastian Dröge <sebastian at centricular.com>
wrote:

> On Tue, 2019-10-01 at 11:24 -0500, Ben Rush wrote:
> > I might be missing something fundamental with respect to the use of
> > g_assert, but it looks as though it's something intended to be built
> > out of production or "release" code, right?
>
> Assertions are also in release code. If they're hit then the internal
> state of the code is so wrong that there's no reasonable way forward.
> Just compiling them out would cause potentially worse problems :)
>
> > I ask because I've been encountering (on Windows) a number of
> > strange, sudden program "crashes" which, upon adding some program-
> > wide exception trapping code to my server, seems to actually be
> > assert statements executing and taking down the host process. For
> > example, I was notified of an RTSP server in production going down
> > and upon looking at the logs, I see that my trap code generated this
> > stack trace:
> >
> > at 0x7ff93969c902, with code 80000003 in module
> > C:\Windows\System32\KERNELBASE.dll, stack:
> >  ?????, DebugBreak:??????
> > d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\gli
> > b-2.56.1\glib\gutils.c, g_abort:2566
> > d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\gli
> > b-2.56.1\glib\gtestutils.c, g_assertion_message:2533
> > d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\gli
> > b-2.56.1\glib\gtestutils.c, g_assertion_message_expr:2556
> > d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\gst
> > -plugins-base-1.0-1.15.2\gst-libs\gst\rtsp\gstrtspconnection.c,
> > gst_rtsp_source_dispatch_write:3899
>
> This problem should be fixed already, it looks very similar to one of
> the issues that were fixed in the last months. You're using a rather
> old development version of GStreamer (odd minor version number: 15).
> Please try again with 1.16.1, and if the problem still exists please
> create an issue in gitlab. Thanks!
>
> --
> Sebastian Dröge, Centricular Ltd · https://www.centricular.com
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20191001/7f2044aa/attachment.html>