Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow
От | Tom Lane |
---|---|
Тема | Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow |
Дата | |
Msg-id | 28906.1499292236@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bitoverflow (Sergey Koposov <skoposov@cmu.edu>) |
Ответы |
Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bitoverflow
|
Список | pgsql-bugs |
Sergey Koposov <skoposov@cmu.edu> writes: > On Thu, 2017-06-29 at 10:00 -0700, Peter Geoghegan wrote: >> This is an oversight in commit 263865a. The fix is to use a variable >> that won't overflow in tuplesort_heap_siftup() -- this is probably a >> one-liner, because when the variable overflows today, the correct >> behavior would be for control to break out of the loop that declares >> the overflowing variable "j", and, I don't see any similar problem in >> other heap maintenance routines. It's a very isolated problem. >> >> I could write a patch. > Just to avoid being forgotten, I attach a trivial patch against 9.5 > branch as well as have created a commitfest submission > https://commitfest.postgresql.org/14/1189/ I don't like s/int/int64/g as a fix for this. That loop is probably a hot spot, and this fix is going to be expensive on any machine where int64 isn't the native word width. How about something like this instead: - int j = 2 * i + 1; + int j; + if (unlikely(i > INT_MAX / 2)) + break; /* if j would overflow, we're done */ + j = 2 * i + 1; if (j >= n) break; regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: