Simply revert this commit: bdefa92

We also need something to suppress TSan.

We failed to suppress TSan on function level, now let's do it on target level:

set_source_files_properties(file PROPERTIES COMPILE_FLAGS option)

Sandbox error:

ResourceNotAvailable: {74f3cad3:8}: sandbox.agentr.errors.ResourceNotAvailable('Resource #1871059875 is not available at all sources [].',)

Will try again...

It did not help... this is ridiculous.

https://clickhouse-test-reports.s3.yandex.net/17630/8239df16039b13d83fe5ed2c8773e7c37a213995/functional_stateless_tests_(thread)/stderr.log

Did not help again... maybe I will try to do some magic. I really need this PR to be merged :)

Cannot reproduce TSan report on my machine...

Reproduced.

Fixed.

Not fixed?

@amosbird I just read what TSan said.

First it said that we can read stack_trace variable while it's being written by the signal handler.
We ensure that it does not happen by:

• mutex in a function that is sending signals;
• skipping signals that come from other processes - theoretically it's not enough as signal can be send from other threads, though we don't do that;
• synchronizing via pipe - but it's not enough as we read from pipe with timeout (100 ms) and it's possible that previous invocation of the signal handler is still in progress (it was checked for sequence_num then paused for a second) and it will write stack_trace when we already processing the next invocation.

So, TSan was right and I protected from this case with data_ready_num, so we cannot read stack_trace value that was not written yet.

Then TSan said that we can write to stack_trace variable from concurrent invocations of signal handlers. I protected from it with signal_latch, so no concurrent invocations of the signal handler possible.

PS. It's too complex for the two reasons:

• it's not allowed to use any complicated synchronization in signal handlers - only atomics and read/write to file descriptor;
• we pass data via global variables.

The latter is not necessarily - what if don't use global variables and simply pass all data via pipe?
If we will do it in single write operation, it will not even require to protect from concurrent invocations of the signal handler.
This method is already used in BaseDaemon for fault signals.

The only difficulty is that we read from pipe with timeout, so we have to implement ReadBufferFromFileDescriptorWithTimeout.
Maybe the code will be more simple.

I don't understand why changing expected_pid from global const to mutable leads to this TSan mess... Isn't it related to stack_trace variable instead?

I don't understand why changing expected_pid from global const to mutable leads to this TSan mess...

I'm only about races on stack_trace variable.
Changes to expected_pid look irrelevant for TSan.