How to test Postgres for any unaligned memory accesses?

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: How to test Postgres for any unaligned memory accesses?
Date: 2021-04-23 10:21:10
Message-ID: CALj2ACXpHCGnr1nzz4azFVKT9hmNKLC7oKoyTD6CO7eJuniWbQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I'm trying to test Postgres code for any unaligned memory accesses. I
used a hack shown at [1] and put it in exec_simple_query, then I'm
seeing a SIGBUS error from SplitIdentifierString's strncpy, see [2].
It looks like the SIGBUS error occurs even if a simple memcpy(for
testing purpose) is done in recomputeNamespacePath or
SplitIdentifierString.

I'm not sure this is the right way. I would like to know whether there
is a standard way of testing Postgres code for any unaligned memory
accesses. Thanks. Any help would be appreciated.

[1] - https://www.programmersought.com/article/17701994124/
+/* Enable Alignment Checking */
+#if defined(__GNUC__)
+# if defined(__i386__)
+ /* Enable Alignment Checking on x86 */
+ __asm__("pushf\norl $0x40000,(%esp)\npopf");
+# elif defined(__x86_64__)
+ /* Enable Alignment Checking on x86_64 */
+ __asm__("pushf\norl $0x40000,(%rsp)\npopf");
+# endif
+#endif

[2]
Program received signal SIGBUS, Bus error.
0x00007f5067188d36 in __strncpy_sse2_unaligned () from /lib64/libc.so.6
(gdb) bt
#0 0x00007f5067188d36 in __strncpy_sse2_unaligned () from /lib64/libc.so.6
#1 0x0000000000ada740 in SplitIdentifierString (rawstring=0x1146620 "\"$user",
separator=44 ',', namelist=0x7ffcdf1911d0) at varlena.c:3817
#2 0x00000000005d203b in recomputeNamespacePath () at namespace.c:3761
#3 0x00000000005cde11 in FuncnameGetCandidates (names=0x1145e08,
nargs=2, argnames=0x0,
expand_variadic=true, expand_defaults=true, missing_ok=false) at
namespace.c:971
#4 0x0000000000647dcb in func_get_detail (funcname=0x1145e08, fargs=0x1146570,
fargnames=0x0, nargs=2, argtypes=0x7ffcdf191540, expand_variadic=true,
expand_defaults=true, funcid=0x7ffcdf1916d8, rettype=0x7ffcdf1916dc,
retset=0x7ffcdf19152f, nvargs=0x7ffcdf191528, vatype=0x7ffcdf191524,
true_typeids=0x7ffcdf191538, argdefaults=0x7ffcdf191530) at
parse_func.c:1421
#5 0x0000000000645961 in ParseFuncOrColumn (pstate=0x11462e8,
funcname=0x1145e08,
fargs=0x1146570, last_srf=0x0, fn=0x1145f28, proc_call=false, location=14)
at parse_func.c:265

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2021-04-23 10:40:33 Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Previous Message Andrey Borodin 2021-04-23 10:19:49 Re: Disallow cancellation of waiting for synchronous replication