On Wed, Mar 27, 2013 at 9:03 AM, Heikki Linnakangas
wrote:
> Writing it like that suggests that autovac might sometimes be NULL, even if
> deadlock_state == DS_BLOCKED_BY_AUTOVACUUM. From your explanation above, I
> gather that's not possible (and I think you're right), so the NULL check is
> unne
should we move the dereference
`autovac->pgprocno' after the check? Thanks.
On Sat, Mar 23, 2013 at 6:38 PM, Xi Wang wrote:
> CHECK_STACK_DEPTH checks if errordata_stack_depth is negative.
> Move the dereference of &errordata[errordata_stack_depth] after
> the check to av
CHECK_STACK_DEPTH checks if errordata_stack_depth is negative.
Move the dereference of &errordata[errordata_stack_depth] after
the check to avoid out-of-bounds read.
---
src/backend/utils/error/elog.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/backend/utils/error
It depends on the context. In the patches, `a' is known to be
non-negative, so `INT_MAX - a' cannot overflow. If you ignore the
context and talk about the general case, then it can.
- xi
On Sat, Feb 23, 2013 at 12:25 PM, Tom Lane wrote:
> Greg Stark writes:
>> He's changing things to do
>
>>
On 1/24/13 10:48 AM, Tom Lane wrote:
> The fundamental problem here is that the compiler, unless told otherwise
> by a compilation switch, believes it is entitled to assume that no
> integer overflow will happen anywhere in the program. Therefore, any
> error check that is looking for overflow *sh
On 1/24/13 5:02 AM, Heikki Linnakangas wrote:
> These patches look ok at a quick glance, but how do we ensure this kind
> of problems don't crop back again in the future? Does icc give a warning
> about these? Do we have a buildfarm animal that produces the warnings?
>
> If we fix these, can we
icc optimizes away `check + VARHDRSZ <= check' since signed integer
overflow is undefined behavior. Simplify the overflow check for
`VARHDRSZ + count * slen' as `count > (INT_MAX - VARHDRSZ) / slen'.
---
src/backend/utils/adt/oracle_compat.c | 18 +++---
1 file changed, 7 insertions
icc optimizes away x + 1 < x because signed integer overflow is
undefined behavior in C. Instead, simply check if x is INT_MAX.
---
src/backend/utils/adt/float.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/backend/utils/adt/float.c b/src/backend/utils/adt/fl
icc optimizes away the overflow check x + y < x (y > 0), because
signed integer overflow is undefined behavior in C. Instead, use
a safe precondition test x > INT_MAX - y.
---
src/backend/utils/adt/varbit.c |7 +--
src/backend/utils/adt/varlena.c | 10 ++
src/pl/plpgsql/src/pl_
na.c | 10 ++
src/pl/plpgsql/src/pl_exec.c |4 ++--
5 files changed, 24 insertions(+), 23 deletions(-)
On 1/20/13 2:58 AM, Xi Wang wrote:
> Intel's icc and PathScale's pathcc compilers optimize away several
> overflow checks, since they consider signe
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they consider signed integer overflow as
undefined behavior. This leads to a vulnerable binary.
Currently we use -fwrapv to disable such (mis)optimizations in gcc,
but not in other compilers.
Examples
On 1/20/13 10:35 PM, Tom Lane wrote:
Great catch, will commit. (But first I'm looking through commit
2594cf0e to see if I made the same mistake anywhere else :-(.)
How did you find that, coverity or some such tool?
Thanks for reviewing the patch.
It was found using a homemade static undefine
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they consider signed integer overflow as
undefined behavior. This leads to a vulnerable binary.
Currently we use -fwrapv to disable such (mis)optimizations in gcc,
but not in other compilers.
Examples
Don't write past the end of tborder; the size is width + 1.
---
src/interfaces/libpq/fe-print.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/interfaces/libpq/fe-print.c b/src/interfaces/libpq/fe-print.c
index 076e1cc..7ed489a 100644
--- a/src/interfaces/libpq/fe-print
The correct NULL check should use `*newval'; `newval' must be non-null.
---
src/backend/utils/cache/ts_cache.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/utils/cache/ts_cache.c
b/src/backend/utils/cache/ts_cache.c
index e688b1a..65a8ad7 100644
--- a/src/bac
On 11/19/12 11:04 AM, Tom Lane wrote:
> I thought about this some more and realized that we can handle it
> by realizing that division by -1 is the same as negation, and so
> we can copy the method used in int4um. So the code would look like
>
> if (arg2 == -1)
> {
> res
On 11/18/12 6:47 PM, Tom Lane wrote:
> Xi Wang writes:
>> [ patch adding a bunch of explicit INT_MIN/MAX constants ]
>
> I was against this style of coding before, and I still am.
> For one thing, it's just about certain to introduce conflicts
> against system headers.
The INT_MIN / -1 crash problem was partially addressed in 2006 and
commit 9fc6f4e1ae107f44807c4906105e1f7eb052ecb1.
http://archives.postgresql.org/pgsql-patches/2006-06/msg00102.php
However, the fix is incomplete and incorrect for some cases.
64-bit crash
Below is an example that c
On 11/14/12 5:03 PM, Tom Lane wrote:
> No need, I'm already patching it.
Oops. Sorry. Ignore my patches.
- xi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Since x % -1 returns 0 for any x, we don't need the check x == INT_MIN.
Suggested by Tom Lane.
---
src/backend/utils/adt/int.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/utils/adt/int.c b/src/backend/utils/adt/int.c
index 4be3901..3e423fe 100644
--- a/src/b
Return 0 for x % -1 instead of throwing an exception (e.g., when x
is INT_MIN).
Suggested by Tom Lane.
---
src/backend/utils/adt/int8.c |4
1 file changed, 4 insertions(+)
diff --git a/src/backend/utils/adt/int8.c b/src/backend/utils/adt/int8.c
index 0e59956..a30ab36 100644
--- a/src/ba
On 11/14/12 4:46 PM, Tom Lane wrote:
> Meh. I didn't care for the explicit dependency on INT_MIN in the
> previous patch, and I like introducing INT64_MIN even less. I think
> we should be able to reduce the test to just
>
> if (arg2 == -1)
> return 0;
>
> since zero is the
Return 0 for INT_MIN % -1 (64-bit) instead of throwing an exception.
This patch complements commit f9ac414c that fixed int4mod().
---
src/backend/utils/adt/int8.c |4
src/include/c.h |7 +++
2 files changed, 11 insertions(+)
diff --git a/src/backend/utils/adt/int8.c
23 matches
Mail list logo
