Bug #3813

osmo_select_main() isn't resetting logging context between callbacks

Added by laforge almost 2 years ago. Updated almost 2 years ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


When we use log_st_context() in Osmocom programs, we do this in the course of processing a packet. Typically it's because a given packet/message was received from some remote entity. Once we know which subscriber/connection/whatever a packet belongs to, we set the log context because that's how our log filters work.

Most of the applications then call log_reset_context() just before calling osmo_select_main(). Not that only most, not all applications do that. For example, OsmoPCU doesn't do that.

However, even for those applications that have an explicit log_reset_context() call before osmo_select_main(): osmo_select_main() can very well call any number of callback functions for any number of file descriptors in one iteration. This means that the log context survives between those select callbacks.


#1 Updated by laforge almost 2 years ago

My proposal is to simply include the log_reset_context() call into osmo_fd_disp_fds(), i.e. make sure that it is called just before entering the respective filedescriptor callback function.

My assumption is that any existing Osmocom code would only benefit from this, i.e. it would fix real bugs. Of course there could be other use casese where people use the log context for something that's intended to persist even across file-descriptor callbacks. But do we know any of them? Do we care?

#2 Updated by laforge almost 2 years ago

#3 Updated by laforge almost 2 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

patch merged

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)