Skip to content

data race in OPENSSL_sk_num #80160

@CheSema

Description

@CheSema

I faced a sanitazer report in the CI

full report: https://s3.amazonaws.com/clickhouse-test-reports/PRs/79963/1cde959f33ad5a23e68a0f52365000c2da5455df//integration_tests_tsan_2_6/integration_run_parallel4_0.log
read write stack: https://pastila.nl/?001166e3/2c2a085d64d5295b50a2d12dcf1fc1a5#h0aJA5qyZg7fiZkrXJC2EQ==

As I read here openssl/openssl#24480
openssl/openssl#24480 (comment)

An SSL_CTX object should not be changed after it is used to create any SSL objects or from multiple threads concurrently, since the implementation does not provide serialization of access for these cases.

And the load operations mutate the SSL_CTX object, by adding certificate location to an internal list.
The appropriate approach here is to call all the mutation functions for the SSL_CTX objects prior to passing to threads for use, so that the shared object can be used in an immutable fashion.

I'm not sure that Clickhouse follows this rule.
May be we need to reorganize our Storages initialization. Now, the one storage is adding certs, other is already firing the requests over ssl.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions