Re: [BUG] PostgreSQL crashes with ThreadSanitizer during early initialization - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUG] PostgreSQL crashes with ThreadSanitizer during early initialization
Date
Msg-id 707073.1762305575@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUG] PostgreSQL crashes with ThreadSanitizer during early initialization  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-hackers
Jacob Champion <jacob.champion@enterprisedb.com> writes:
> On Tue, Nov 4, 2025 at 2:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Another problem is that it only defends against a limited set of
>> sanitizers, though presumably every single one is broken in the same
>> way (compare [1]).

> How about __attribute__((disable_sanitizer_instrumentation)) ? LLVM's
> own tests make some use of this [1].

Hah, thanks for the research!  For me, this stops the failure
(on RHEL9 with clang version 19.1.7):

diff --git a/src/backend/main/main.c b/src/backend/main/main.c
index bdcb5e4f261..1bd63ec9184 100644
--- a/src/backend/main/main.c
+++ b/src/backend/main/main.c
@@ -500,6 +500,10 @@ check_root(const char *progname)
  * seem necessary to only compile it conditionally.
  */
 const char *__ubsan_default_options(void);
+
+#if __has_attribute(disable_sanitizer_instrumentation)
+__attribute__((disable_sanitizer_instrumentation))
+#endif
 const char *
 __ubsan_default_options(void)
 {

Assuming that works for Emmanuel, we could wrap it in a
pg_disable_sanitizer_instrumentation macro, or just use it
as-is.  I don't have a strong preference --- any thoughts?

(It could do with a comment, either way.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Naga Appani
Date:
Subject: Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Next
From: Tom Lane
Date:
Subject: Re: ubsan