GNOME Bugzilla – Bug 785035
debug: Add a memory ringbuffer based debug logger
Last modified: 2017-08-08 08:11:46 UTC
See commit message
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.
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?
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.
Attachment 355804 [details] pushed as ad0dd86 - debug: Add a memory ringbuffer based debug logger
How would one use this. Programmatically while a thread is operating with rt- privileges?
What are you asking exactly? It's not really any different in that respect than having logging enabled in general, is it?
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?
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.
Thanks for the explanation. I think this would make a great addition to the docs.