Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-531

wiredtiger_open might leak resources on open

    • Type: Icon: Task Task
    • Resolution: Done
    • WT1.6.0
    • Affects Version/s: None
    • Component/s: None
    • Labels:

      In writing the logging code, particularly right now, thinking about configuration, starting an archiving thread, etc, I've been looking a lot at the checkpoint and statistics log code. Logging will likely be modeled on those.

      In reading that code, I believe that we leak resources if an error occurs with any of those. Let's assume the user specified maximal resources (i.e. checkpoint name is allocated, ckpt thread is running, a ckpt cond var is allocated, same with stats log path, condvar etc.). We're at the end of *wt_statlog_create and there is some error starting the statlog thread. It uses WT_RET and will return an error from *wt_statlog_create.

      Its (only) caller, *wt_connection_open called it with WT_ERR. We go to the err: label and call *wt_connection_close. That function is below the only caller (*conn_close) of the *wt_statlog_destroy and __wt_checkpoint_destroy.

      So, on an error, the checkpoint thread and both subsystems' resources are left running/allocated and wiredtiger_open will return an error.

      The comment in *conn_close stifles my first instinct to simply move those _destroy functions to the beginning of *wt_connection_close, i.e. the threads may access btree handles and care must be taken in shutdown order to make sure they exit before closing the handles.

      Which, if any, of these options is correct:
      1. Add calls to the *wt_checkpoint/statlog_destroy functions at the err label in *wt_connection_open, before it calls __wt_connection_close.

      2. WT-1 may not be wholly correct if other things have been allocated or in use as well. So perhaps the err label in *wt_connection_open should call *conn_close instead of __wt_connection_close.

      3. Some other idea.

            Assignee:
            sue.loverso@mongodb.com Susan LoVerso
            Reporter:
            sue.loverso@mongodb.com Susan LoVerso
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: