From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: init_htab causes SIGFPE (or worse) due to miscalculation for large nbuckets |
Date: | 2012-12-09 22:45:32 |
Message-ID: | 18018.1355093132@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> If nbuckets is around 2^30+1, which can happen if work_mem is very high,
> then:
> nbuckets = 1 << my_log2(lnbuckets);
> ends up as 1 << 31, which is negative, leading to a SIGFPE on my
> machine, but I think it can also lead to an infinite loop or a crash
> (after corrupting the HASHHDR).
> ...
> I think we should just cap nbuckets at 1 << 30 in init_htab.
Yeah. After looking at other uses of my_log2, it seems like
hash_estimate_size and hash_select_dirsize probably should also
bound their inputs to avoid overflow of 1 << my_log2() calculations.
Alternatively, maybe we should hack my_log2 to do that bounding.
As-is, it seems like trouble waiting to happen. This won't protect
init_htab, which needs the shift result to fit in int not long.
But my_log2 is just plain broken for inputs larger than LONG_MAX/2,
anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2012-12-10 04:13:07 | Re: BUG #7748: "drop owned by" fails with error message: "unrecognized object class: 1262" |
Previous Message | Thomas Kellerer | 2012-12-09 22:44:13 | Re: BUG #7748: "drop owned by" fails with error message: "unrecognized object class: 1262" |