Re: Remove dependence on integer wrapping - Mailing list pgsql-hackers
From | Alexander Lakhin |
---|---|
Subject | Re: Remove dependence on integer wrapping |
Date | |
Msg-id | bfff906f-300d-81ea-83b7-f2c93845e7f2@gmail.com Whole thread Raw |
In response to | Re: Remove dependence on integer wrapping (Nathan Bossart <nathandbossart@gmail.com>) |
Responses |
Re: Remove dependence on integer wrapping
|
List | pgsql-hackers |
Hello Nathan and Joe, 16.08.2024 19:52, Nathan Bossart wrote: > On Thu, Aug 15, 2024 at 10:49:46PM -0400, Joseph Koshakow wrote: >> This updated version LGTM, I agree it's a good use of pg_abs_s32(). > Committed. Thank you for working on that issue! I've tried `make check` with CC=gcc-13 CPPFLAGS="-O0 -ftrapv" and got a server crash: 2024-08-16 17:14:36.102 UTC postmaster[1982703] LOG: (PID 1983867) was terminated by signal 6: Aborted 2024-08-16 17:14:36.102 UTC postmaster[1982703] DETAIL: Failed process was running: select '[]'::jsonb ->> -2147483648; with the stack trace ... #5 0x0000556aec224a11 in __negvsi2 () #6 0x0000556aec046238 in jsonb_array_element_text (fcinfo=0x556aedd70240) at jsonfuncs.c:993 #7 0x0000556aebc90b68 in ExecInterpExpr (state=0x556aedd70160, econtext=0x556aedd706a0, isnull=0x7ffdf82211e4) at execExprInterp.c:765 ... (gdb) f 6 #6 0x0000556aec046238 in jsonb_array_element_text (fcinfo=0x556aedd70240) at jsonfuncs.c:993 993 if (-element > nelements) (gdb) p element $1 = -2147483648 Sp it looks like jsonb_array_element_text() still needs the same treatment as jsonb_array_element(). Moreover, I tried to use "-ftrapv" on 32-bit Debian and came across another failure: select '9223372036854775807'::int8 * 2147483648::int8; server closed the connection unexpectedly ... #4 0xb722226a in __GI_abort () at ./stdlib/abort.c:79 #5 0x004cb2e1 in __mulvdi3.cold () #6 0x00abe7ab in pg_mul_s64_overflow (a=9223372036854775807, b=2147483648, result=0xbff1da68) at ../../../../src/include/common/int.h:264 #7 0x00abfbff in int8mul (fcinfo=0x14d9d04) at int8.c:496 #8 0x00782675 in ExecInterpExpr (state=0x14d9c4c, econtext=0x14da15c, isnull=0xbff1dc3f) at execExprInterp.c:765 Whilst select '9223372036854775807'::int8 * 2147483647::int8; emits ERROR: bigint out of range I've also discovered another trap-triggering case for a 64-bit platform: select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1 union all select 1; server closed the connection unexpectedly ... #5 0x00005576cfb1c9f3 in __negvdi2 () #6 0x00005576cf627c68 in bms_singleton_member (a=0x5576d09f7fb0) at bitmapset.c:691 #7 0x00005576cf72be0f in fix_append_rel_relids (root=0x5576d09df198, varno=31, subrelids=0x5576d09f7fb0) at prepjointree.c:3830 #8 0x00005576cf7278c2 in pull_up_simple_subquery (root=0x5576d09df198, jtnode=0x5576d09f7470, rte=0x5576d09de300, lowest_outer_join=0x0, containing_appendrel=0x5576d09f7368) at prepjointree.c:1277 ... (gdb) f 6 #6 0x00005576cf627c68 in bms_singleton_member (a=0x5576d09f7fb0) at bitmapset.c:691 691 if (result >= 0 || HAS_MULTIPLE_ONES(w)) (gdb) p/x w $1 = 0x8000000000000000 Best regards, Alexander
pgsql-hackers by date: