Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Leftover logfile is close()d … unpredictably? #39
The above code illustrates a problem where a 2nd context creation will clobber a leftover logfile from a former context.
It seems like the ideal fix would be to put the log state variables into the context struct rather than having them be globals?
(I haven’t tested it, but it looks like, given the globals, it would be problematic, for example, to have two concurrent Unbound objects in the same process with different log outputs?)
Failing that change … is there any way to fix this, short of removing that fclose() in log.c (and potentially breaking behavior that implementations may have been expecting now for over 10 years)?
Regardless, it seems like this issue should at least be documented? The existing libunbound(3) documentation for ub_ctx_debugout() gives the impression that log state is contained entirely within the log object, which of course isn’t the case.
The workaround seems to be to set the log handle to stderr before deleting the context … does that seem reasonable?
Have you tried _IOLBF ? The line buffer should correspond nicely to the line-at-a-time log entries, when you use two contexts at the same time.
This is the workaround that I have in place in my calling code. It seems to fix this particular issue, yes. :)
There seems to be a related problem, where anything that depends on the global
I’ve not analyzed the code enough to determine if this causes “real” breakage.