Project

General

Profile

Actions

Bug #11408

closed

Concurrency issues that thread sanitizer found

Added by Roel Standaert about 1 year ago. Updated 7 months ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
03/07/2023
Due date:
% Done:

100%

Estimated time:

Description

Running test.http with thread sanitizer yields a few issues:

  • Wt::Http::Client: concurrent reads and writes of the impl_ weak_ptr: abort() can be called concurrently with emitDone(), and abort() calls impl_.lock() while emitDone reset()s it. Since we don't have a std::atomic<std::weak_ptr<...>> in C++14 we should probably guard it with a mutex. (Note: while the reference count itself is atomic for a shared_ptr and weak_ptr, the operations on a specific weak_ptr are NOT atomic.) (log 1)
  • Wt::Http::ResponseContinuation: concurrent reads and writes to waiting_: haveMoreData() reads waiting_ while waitForMoreData() writes to it
  • ResponseContinuation::resource_ is read in haveMoreData() (while we have a lock on mutex_), while Response::createContinuation() may write to it (log 1)
  • WebController: concurrent reads and writes to running_: when WServer::stop() is called running_ is set to false (mutex_ is locked there). handleRequest and requestDataReceived check running_ without locking mutex_. Either we need to add an appropriate lock when checking running_, or running_ should be turned into an std::atomic_bool.
  • http_client_server_test4 checks isDone(), which reads done_ without a lock, while onDone may be writing to it. We can grab the doneMutex_ when checking isDone(). (log 1)
  • Signal-related races that I think might be test-specific. (log 1)

I found these when looking into issues #11301 and #11302.


Files

out1.log.gz (117 KB) out1.log.gz Log of test.http with thread sanitizer Roel Standaert, 03/08/2023 12:31 PM

Related issues 2 (0 open2 closed)

Related to Bug #11301: test.http server race can result in use-after-freeClosedRoel Standaert02/01/2023

Actions
Related to Bug #11302: Race when closing HTTP listening sockets can result in use-after-freeClosedMatthias Van Ceulebroeck02/02/2023

Actions
Actions #1

Updated by Roel Standaert about 1 year ago

  • Related to Bug #11301: test.http server race can result in use-after-free added
Actions #2

Updated by Roel Standaert about 1 year ago

  • Related to Bug #11302: Race when closing HTTP listening sockets can result in use-after-free added
Actions #3

Updated by Roel Standaert about 1 year ago

  • Description updated (diff)
Actions #4

Updated by Matthias Van Ceulebroeck 11 months ago

  • Target version changed from 4.10.0 to 4.10.1
Actions #5

Updated by Matthias Van Ceulebroeck 9 months ago

  • Status changed from New to InProgress
  • Assignee set to Matthias Van Ceulebroeck
Actions #6

Updated by Matthias Van Ceulebroeck 9 months ago

  • Status changed from InProgress to Review
  • Assignee deleted (Matthias Van Ceulebroeck)
Actions #7

Updated by Matthias Van Ceulebroeck 9 months ago

  • Assignee set to Marnik Roosen
Actions #8

Updated by Matthias Van Ceulebroeck 9 months ago

  • Status changed from Review to Implemented @Emweb
  • Assignee changed from Marnik Roosen to Matthias Van Ceulebroeck
Actions #9

Updated by Matthias Van Ceulebroeck 9 months ago

  • % Done changed from 0 to 100
Actions #10

Updated by Matthias Van Ceulebroeck 7 months ago

  • Status changed from Implemented @Emweb to Closed
Actions

Also available in: Atom PDF