Re: BUG #16456: Implicit unsigned integer truncation atmultixact.c:2626
От | Kyotaro Horiguchi |
---|---|
Тема | Re: BUG #16456: Implicit unsigned integer truncation atmultixact.c:2626 |
Дата | |
Msg-id | 20200525.135828.2152046213298490507.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | BUG #16456: Implicit unsigned integer truncation at multixact.c:2626 (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
Hello. At Sat, 23 May 2020 14:21:38 +0000, PG Bug reporting form <noreply@postgresql.org> wrote in > REPRODUCTION && ERROR MESSAGE: > > compile the postgres project with UndefinedBehaviorSanitizer and start a > start a server with "postgress" (command: "./postgres -Ddata -p23333"), and > Ubsan reported an error message: I'm not sure how the UndefinedBehaviorSanitizer works in details, but the output of such kind of tools should need examiniations considering the context of the code around. > multixact.c:2626:19: runtime error: implicit conversion from type 'unsigned > long' of value 18446744073709499264 (64-bit, unsigned) to type > 'MultiXactOffset' (aka 'unsigned int') changed the value to 42949 > 14944 (32-bit, unsigned) ... > ROOT CAUSE CODE > > The root cause code are shown bellow (multixact.c:2626). I believe that > *offsetStopLimit* is a uint32 and *MULTIXACT_MEMBERS_PER_PAGE * > SLRU_PAGES_PER_SEGMENT* cannot presented as uint32. The variable is used in a wrap-arounded way. Although the intermediate result tentatively becomes 64bits long because of size_t contained in the expression, the result logically doesn't go beyond 32bit range and no bits of information are not lost through the down conversion. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-bugs по дате отправления: