g_assert in production code?

[Ben Rush]

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? 

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\glib-2.56.1\glib\gutils.c, g_abort:2566
d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\glib-2.56.1\glib\gtestutils.c, g_assertion_message:2533
d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\glib-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
d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\glib-2.56.1\glib\gmain.c, g_main_dispatch:3261
d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\glib-2.56.1\glib\gmain.c, g_main_context_dispatch:3966
d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\glib-2.56.1\glib\gmain.c, g_main_context_iterate:4036
d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\glib-2.56.1\glib\gmain.c, g_main_loop_run:4230
d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\gst-rtsp-server-1.0-1.15.2\gst\rtsp-server\rtsp-thread-pool.c, do_loop:331
d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\glib-2.56.1\glib\gthreadpool.c, g_thread_pool_thread_proxy:308
d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\glib-2.56.1\glib\gthread.c, g_thread_proxy:784
d:\projects\cerbero\autotools\master\build\sources\windows_x86_64\glib-2.56.1\glib\gthread-win32.c, g_thread_win32_proxy:452
?????, o_strcat_s:??????
?????, BaseThreadInitThunk:??????
?????, RtlUserThreadStart:??????

It looks like it makes its way down to g_abort, which sure seems to be involved in program termination. It's possible this is a red herring and that I should ignore such things, but my spidey sense is telling me this assert should be a noop in production code. 

Is it possible the Windows build isn't doing this? 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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() 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 <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel