GNOME Bugzilla – Bug 674930
Logging to a file causes loss of logs when forking
Last modified: 2016-10-29 14:51:37 UTC
GST_DEBUG=5 GST_DEBUG_FILE=gst.log gst-inspect -a gst.log will be corrupt. This happens when more than one process spawned by the gst using program tries to open the log file for writing. I guess it could be solved by having a semaphore protect writes to the file, but that might cause a large slowdown (not tried). Preventing all but the first log prevents the corruption, but also loses the logs from those processes. Another way could be to let subsequent processes open a different file, maybe named with their PID as a suffix (maybe using % format string in the GST_DEBUG_FILE variable, such as "gst.%p.log", and replacing %p by PID. Could do that for date/time too).
Can't reproduce. Seems to have been fixed on master. Is anyone still experiencing this? Vincent: Any chances you can elaborate on what's intended here by "corrupt"? A sample log file showing the issue would be great too.
It is unclear to me what would have fixed this though.
Yeah, there wasn't really something that touched this code. Writing to the same file from multiple processes at the same time just has this behaviour unless you explicitly synchronize the processes or just use different files. I think something like Vincent's suggestion to use %p makes sense, and additionally lock the file so that if it's still the same file only the first process can ever write to it.
Created attachment 259011 [details] log file (with colors)
Then and as I mention before I'm not getting the meaning of 'corruption' right. I'm attaching somewhat of a huge 14M log captured with the description cmd line (compressed). Can anyone point out where is this corruption visible on the file? Was tempted to go GST_DEBUG_NO_COLOR but went without it (tried though and didn't see any 'corruption' neither).
Your logging file output is all from one process...
Created attachment 259012 [details] Showing corruption I don't have an up to date master to test with, but with good old 0.10.36, this is what corruption is like. I had to rm ~/.gstreamer-0.10/registry* for this to happen (line 96). Lots of zeroes which make me think of concurrent accesses in write mode. If this doesn't happen with master after removing registries (if they still exist in 1.0), then this can be closed I guess.
Oh, my bad. Was testing from an uninstalled environment and had to remove gstreamer/registry.dat to reproduce. Confirmed them ;) file gets corrupted with the aforementioned cmd line, with master as of today and under the conditions outlined by Vincent.
Created attachment 338611 [details] [review] Allow %p in log file
*** This bug has been marked as a duplicate of bug 773092 ***
Good timing :D