| From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
|---|---|
| To: | Tristan Partin <tristan(at)neon(dot)tech>, Michael Meskes <meskes(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fix some memory leaks in ecpg.addons |
| Date: | 2023-11-08 19:00:00 |
| Message-ID: | 87527c05-95fa-2fb9-14e2-4feb74af5e9e@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello Tristan,
08.11.2023 20:37, Tristan Partin wrote:
> Are people using some suppression file or setting ASAN_OPTIONS to something?
>
I use the following:
ASAN_OPTIONS=detect_leaks=0:abort_on_error=1:print_stacktrace=1:\
disable_coredump=0:strict_string_checks=1:check_initialization_order=1:\
strict_init_order=1:detect_stack_use_after_return=0
(You'll need to add detect_stack_use_after_return=0 with a newer clang
(I use clang-18) to workaround an incompatibility of check_stack_depth()
with that sanitizer feature enabled by default.)
There is also another story with hwasan ([1]).
and yet another incompatibility of check_stack_depth() related to the
aarch64-specific address tagging (TBI).
So I would say that fixing ecpg won't make postgres sanitizer-friendly in
a whole.
[1] https://www.postgresql.org/message-id/dbf77bf7-6e54-ed8a-c4ae-d196eeb664ce%40gmail.com
Best regards,
Alexander
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2023-11-08 19:00:18 | Re: [PoC] Federated Authn/z with OAUTHBEARER |
| Previous Message | Bruce Momjian | 2023-11-08 18:50:37 | Re: XID-wraparound hazards in LISTEN/NOTIFY |