-
Notifications
You must be signed in to change notification settings - Fork 714
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ThreadSanitizer: data race during ResponseWriter destructor #1297
Comments
Hi @TheQue42, Thanks for reporting this issue. I don't have an immediate answer, but let me note a couple of thoughts. First glance, it looks quite odd. For thread T10, the place where the problem is identified in transport.cc:233 looks like this:
The problem happens in the destructor of the shared pointer Per ThreadSanitizer, the second 32-bit-word of the same location being written to by the shared pointer destructor was also written to in thread T6 by the weak pointer destructor for We can perhaps guess that the But the strangeness here is that I would expect it to be perfectly OK for a weak pointer to an object to go out of scope asynchronously with a shared pointer. Surely that's one design criteria for weak pointers, unless I'm missing something. The fact that thread T10 is doing a 64-bit write, while T6 is doing a 32-bit atomic write, might be indicative of a larger memory corruption / heap corruption issue, since the writes seem mismatched. transport.cc/.h does pass references to Experiments to try:
If it practical for you to make each of those changes, recompile Pistache, and then retry your scenario? |
I just did a quick try of your suggestions, and doesnt look like it made any difference! |
If there is any other simple modification you want me to try, let me know. I am not very experienced when it comes to interpreting these backtraces, so I wont get far on my own I think. Do we have tests in the repo, that does anything similar as my use-case? That is, cloning the response-writers and answering in a different thread? If I can, I'll try to see if there is any special use case where this happens. |
Hi,
When testing my own application using GCC's thread sanitizer, I am occasionally receiving complaints with a backtrace that traces all the way down into pistache (when pistache is build with
-fsanitize=thread -fno-omit-frame-pointer
.I am starting pistache via serve(), from its own std::jthread (simply because I got more complaints when using serveThreaded()).
I am using pistache in an asynchronous way, so that when requests are received via my
Rest::Router
to my endpoints, a different thread will fetch the response contents via a proprietary API (aka IMMI), and while waiting for that response I will clone theHttp::ResponseWriter
such as:Once the ImmiHandler receives its results, it uses the
m_rspWriter
to send the response, and eventually the ImmiHandler will die, taking them_rspWriter
with it.But that's were I get (and where I need help analyzing the complaint from GCC 14)
The text was updated successfully, but these errors were encountered: