After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 785035 - debug: Add a memory ringbuffer based debug logger
debug: Add a memory ringbuffer based debug logger
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal enhancement
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-07-17 18:05 UTC by Sebastian Dröge (slomo)
Modified: 2017-08-08 08:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
debug: Add a memory ringbuffer based debug logger (11.18 KB, patch)
2017-07-17 18:05 UTC, Sebastian Dröge (slomo)
none Details | Review
debug: Add a memory ringbuffer based debug logger (10.00 KB, patch)
2017-07-18 08:05 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Sebastian Dröge (slomo) 2017-07-17 18:05:04 UTC
See commit message
Comment 1 Sebastian Dröge (slomo) 2017-07-17 18:05:09 UTC
Created attachment 355774 [details] [review]
debug: Add a memory ringbuffer based debug logger

This stores debug logs in memory per thread and uses up to a
configurable amount of bytes per thread for the logs. Inactive threads
are timed out after a configurable amount of time.
Comment 2 Tim-Philipp Müller 2017-07-17 20:19:00 UTC
Cool stuff. As I mentioned on IRC, since we do the g_strdup_printf() anyway, we might just as well not copy the result into a single ringbuffer allocation area, but instead just keep a queue/list/array of allocated strings and their length around and retire old ones if the size exceeds the allowed size.

If we can somehow use g_vasprintf() we can also avoid that strlen(), but that's all implementation details I suppose.

Would it make sense to make the per-thread size config in kB units instead of bytes?
Comment 3 Sebastian Dröge (slomo) 2017-07-18 08:05:24 UTC
Created attachment 355804 [details] [review]
debug: Add a memory ringbuffer based debug logger

This stores debug logs in memory per thread and uses up to a
configurable amount of bytes per thread for the logs. Inactive threads
are timed out after a configurable amount of time.
Comment 4 Sebastian Dröge (slomo) 2017-07-28 16:29:28 UTC
Attachment 355804 [details] pushed as ad0dd86 - debug: Add a memory ringbuffer based debug logger
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2017-08-07 21:06:35 UTC
How would one use this. Programmatically while a thread is operating with rt- privileges?
Comment 6 Tim-Philipp Müller 2017-08-07 21:18:13 UTC
What are you asking exactly? It's not really any different in that respect than having logging enabled in general, is it?
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2017-08-07 22:59:26 UTC
Sorry if I wasn't clear. To me the API docs are not helpful explaining when to use these new functions over others. Normally people get logs by setting GST_DEBUG and co. env vars. These new functions seem to support a special use case, right?
Comment 8 Sebastian Dröge (slomo) 2017-08-08 07:34:17 UTC
You would for example use this in an application that runs in debug mode for generating some kind of error report. It allows you to get (for each thread) the last log lines programmatically. You don't really want to capture everything, especially for a long running application, but are usually only interested in what happened right before things failed.

GST_DEBUG still sets the categories though, this is just an additional logging function / logger that does not output to stderr (or to a file with GST_DEBUG_FILE), but instead stores things in memory.
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2017-08-08 08:11:46 UTC
Thanks for the explanation. I think this would make a great addition to the docs.