Skip to content

Potential race condition in CachingSession #1420

@Lorak-mmk

Description

@Lorak-mmk

Getting and removing elements from the cache (done in CachingSession::add_prepared_statement_owned) goes roughly as follows:

  1. Try to get element from the map
  2. If it is not present, prepare statement
  3. Check if cache is full
  4. If cache is full, get first statement from it
  5. Remove the statement
  6. Insert new statement

I think the following race might be possible:

  • There are 2 tasks
  • Both try to use different queries that are not in the cache
  • Both notice that, and prepare the statement
  • Both notice that cache is full
  • Both get the same statement string to remove from the cache
  • Both remove this statement from the cache
  • Both insert their queries. Now there are max_capacity + 1 elements in the cache

Potential consequence: we check if self.max_capacity == self.cache.len(), so if cache overflows we will never again remove from it, causing a leak.
Switching to >= will make the impact much less severe. TBH this is not very serious - I doubt that any reasonable app makes so many different requests that this leak would be problematic.

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions