--VrqPEDrXMn8OVzN4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Re: SIGFPE on integer divide.

This signal does appear on linux also. On my 7.4.7 installation it
doesn't because of some problem with the integer conversion code but on
8.2devel it gets a SIGFPE.

DETAIL: An invalid floating-point operation was signaled. This
probably means an out-of-range result or an invalid operation, such as
division by zero.

A simple C program shows the same. Why isn't it being caught on
windows?

Have a nice day,
--=20
Martijn van Oosterhout <kleptog (AT) svana (DOT) org> http://svana.org/kleptog/
--VrqPEDrXMn8OVzN4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEN7dJIB7bNG8LQkwRAoGWAJ9EbrL5OLkIsZBBdqroB5 11Z9PgCgCgh4uM
M2KEktPwCOirilzcnRAXZWg=
=yz/x
-----END PGP SIGNATURE-----

--VrqPEDrXMn8OVzN4--

Martijn van Oosterhout <kleptog (AT) svana (DOT) org> writes:
Hmm, it seems to depend on the hardware you're using. I just tried it
on four different machines:

x86 (Pentium 4): SIGFPE
x86_64 (Xeon EM64T): SIGFPE
HPPA: "ERROR: integer out of range" (the intended behavior)
PPC (Mac OS X): no error, returns zero

So the overflow test in int4div is definitely broken and needs to be
changed. However, this is also a good question:

That still looks like a failure to trap something we should trap.
I'd suggest fixing that first, because if we fix int4div first,
we won't have a simple test case for it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

--tNQTSEo8WG/FKZ8E
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 08, 2006 at 12:27:19PM -0400, Tom Lane wrote:
<no consistancy whatsoever>

Well, we should at least add a regression test for this divide thing
since obviously people assumed it was working when it wasn't.

However, would it be possible to add a test_sigfpe() to regress.c that
simply tries to do 1/0. There is appears to be no regression test that
generates a floating-point exception which appears to be a serious
omission. There are any number of ways to force one: ln(0) for example
(hmm, looks like we protect against that). I suppose one floating point
and one integer example should suffice.

Are there any other signals we should be watching for?

Have a nice day,
--=20
Martijn van Oosterhout <kleptog (AT) svana (DOT) org> http://svana.org/kleptog/
--tNQTSEo8WG/FKZ8E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEN+/3IB7bNG8LQkwRAuMmAJ0eYvJMnTZuPGdtwx4T6mLDIgpAwACgh 1RU
z9YkaMV1GzsD8lA2vs+MYN0=
=kIKX
-----END PGP SIGNATURE-----

--tNQTSEo8WG/FKZ8E--

Martijn van Oosterhout <kleptog (AT) svana (DOT) org> writes:
This seems completely pointless. The question is not about whether the
SIGFPE catcher works when fired, it's about what conditions trigger it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Martijn van Oosterhout <kleptog (AT) svana (DOT) org> writes:
The point here is that under Windows int4div seems to be generating
something other than a SIGFPE --- if it were actually generating that
particular signal then the existing SIGFPE catcher would catch it.

It's barely possible that int4div *is* generating a SIGFPE and there's
some other breakage preventing FloatExceptionHandler from catching it,
but that's a question that deserves a one-shot test, not permanent
memorialization in a regression test. Besides, if that's the situation
then testing that the handler catches kill(SIGFPE) proves exactly zero
about what the int4div problem is.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

--f54savKjS/tSNRaU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 19, 2006 at 10:15:54AM -0400, Tom Lane wrote:
Well, depends how you look at it. The original bug report was about a
backend crash, which is what happens if you don't catch the SIGFPE. Can
we guarentee that we know every situation that might generate a SIGFPE?

Besides, isn't this what you were referring to here:

http://archives.postgresql.org/pgsql...4/msg00091.php

Otherwise we should just fix int4div.
--=20
Martijn van Oosterhout <kleptog (AT) svana (DOT) org> http://svana.org/kleptog/

--f54savKjS/tSNRaU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFERktZIB7bNG8LQkwRAo/NAJ44nElIrmtAsDBeTUPpZgi2KO8YugCgjjc3
LAu/qtbVGbDSWm+dsK0BSVY=
=Jshw
-----END PGP SIGNATURE-----

--f54savKjS/tSNRaU--

--cpvLTH7QU4gwfq3S
Content-Type: multipart/mixed; boundary="ZRyEpB+iJ+qUx0kp"
Content-Disposition: inline


--ZRyEpB+iJ+qUx0kp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[Re: Uncaught exception when dividing integers]

On Tue, Apr 18, 2006 at 10:50:24PM -0400, Bruce Momjian wrote:
Not that I know of. However, the first step is to add this regression
test for SIGFPE [-patches CCed]. Note that this will probably redline
windows on the buildfarm. Once this has been added and all
architechures are in compliance, we can deal with the integer overflow
problem.

Triggering a SIGFPE is a bit tricky. On my i386 system the integer
divide will do it, but the rest just return +inf. Given there are
systems that don't SIGFPE the integer divide, I hope one of the others
will trigger... For UNIX systems I've made it try kill() first, that
seems the most reliable.

Have a nice day,
--=20
Martijn van Oosterhout <kleptog (AT) svana (DOT) org> http://svana.org/kleptog/

--ZRyEpB+iJ+qUx0kp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="sigfpe.diff"
Content-Transfer-Encoding: quoted-printable

? src/test/regress/.deps
? src/test/regress/libregress.so.0.0
? src/test/regress/log
? src/test/regress/pg_regress
? src/test/regress/results
? src/test/regress/testtablespace
? src/test/regress/tmp_check
? src/test/regress/expected/constraints.out
? src/test/regress/expected/copy.out
? src/test/regress/expected/create_function_1.out
? src/test/regress/expected/create_function_2.out
? src/test/regress/expected/misc.out
? src/test/regress/expected/tablespace.out
? src/test/regress/sql/constraints.sql
? src/test/regress/sql/copy.sql
? src/test/regress/sql/create_function_1.sql
? src/test/regress/sql/create_function_2.sql
? src/test/regress/sql/misc.sql
? src/test/regress/sql/tablespace.sql
Index: src/test/regress/regress.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D
RCS file: /projects/cvsroot/pgsql/src/test/regress/regress.c,v
retrieving revision 1.65
diff -u -r1.65 regress.c
--- src/test/regress/regress.c 11 Jan 2006 20:12:43 -0000 1.65
+++ src/test/regress/regress.c 19 Apr 2006 10:16:59 -0000
@@ -10,6 +10,12 @@
#include "executor/executor.h" /* For GetAttributeByName */
#include "commands/sequence.h" /* for nextval() */
=20
+/* For the SIGFPE test */
+#if defined(HAVE_POSIX_SIGNALS) && defined (HAVE_UNISTD_H)
+#include <signal.h>
+#include <unistd.h>
+#endif
+
#define P_MAXDIG 12
#define LDELIM '('
#define RDELIM ')'
@@ -26,7 +32,7 @@
extern int oldstyle_length(int n, text *t);
extern Datum int44in(PG_FUNCTION_ARGS);
extern Datum int44out(PG_FUNCTION_ARGS);
-
+extern Datum sigfpe(PG_FUNCTION_ARGS);
=20
/*
* Distance from a point to a path
@@ -734,3 +740,33 @@
*--walk =3D '\0';
PG_RETURN_CSTRING(result);
}
+
+/*
+ * sigfpe - deliberatly generates a floating point exception
+ */
+PG_FUNCTION_INFO_V1(sigfpe);
+
+Datum
+sigfpe(PG_FUNCTION_ARGS)
+{
+#if defined(HAVE_POSIX_SIGNALS) && defined (HAVE_UNISTD_H)
+ /* Most guarenteed way */
+ kill( getpid(), SIGFPE );
+#endif
+ /* If no signals, try to trigger manually */
+ volatile int int_val =3D 0; /* Avoid compiler constant elimination */
+ volatile float float_val =3D 0;
+
+ char str[12];
+ sprintf( str, "%d", 5/int_val );
+ sprintf( str, "%f", 5.0/float_val );
+=09
+ float_val =3D -10;
+ sprintf( str, "%f", log(float_val) );
+
+ float_val =3D 2e+304;
+ sprintf( str, "%1.f", exp10(float_val) );
+ sprintf( str, "%1.f", float_val * float_val );
+
+ PG_RETURN_VOID();
+}
Index: src/test/regress/expected/errors.out
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D
RCS file: /projects/cvsroot/pgsql/src/test/regress/expected/errors.out,v
retrieving revision 1.52
diff -u -r1.52 errors.out
--- src/test/regress/expected/errors.out 15 Apr 2006 17:45:46 -0000 1.52
+++ src/test/regress/expected/errors.out 19 Apr 2006 10:16:59 -0000
@@ -449,6 +449,10 @@
ERROR: syntax error at or near "NUL"
LINE 16: ...L, id2 TEXT NOT NULL PRIMARY KEY, id3 INTEGER NOT NUL, id4 I...
^
+-- Check that floating point exceptions are properly caught
+select sigfpe();
+ERROR: floating-point exception
+DETAIL: An invalid floating-point operation was signaled. This probably m=
eans an out-of-range result or an invalid operation, such as division by ze=
ro.
-- Check that stack depth detection mechanism works and
-- max_stack_depth is not set too high
create function infinite_recurse() returns int as
Index: src/test/regress/input/create_function_1.source
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D
RCS file: /projects/cvsroot/pgsql/src/test/regress/input/create_function_1.=
source,v
retrieving revision 1.17
diff -u -r1.17 create_function_1.source
--- src/test/regress/input/create_function_1.source 27 Feb 2006 16:09:50 -0=
000 1.17
+++ src/test/regress/input/create_function_1.source 19 Apr 2006 10:16:59 -0=
000
@@ -52,6 +52,11 @@
AS '@abs_builddir@/regress@DLSUFFIX@'
LANGUAGE C STRICT;
=20
+CREATE FUNCTION sigfpe()=20
+ RETURNS void=20
+ AS '@abs_builddir@/regress@DLSUFFIX@'=20
+ LANGUAGE C STRICT;
+
-- Things that shouldn't work:
=20
CREATE FUNCTION test1 (int) RETURNS int LANGUAGE SQL
Index: src/test/regress/sql/errors.sql
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D
RCS file: /projects/cvsroot/pgsql/src/test/regress/sql/errors.sql,v
retrieving revision 1.13
diff -u -r1.13 errors.sql
--- src/test/regress/sql/errors.sql 11 Feb 2005 22:15:12 -0000 1.13
+++ src/test/regress/sql/errors.sql 19 Apr 2006 10:16:59 -0000
@@ -368,9 +368,13 @@
NOT=20
NULL);
=20
+-- Check that floating point exceptions are properly caught
+select sigfpe();
+
-- Check that stack depth detection mechanism works and
-- max_stack_depth is not set too high
create function infinite_recurse() returns int as
'select infinite_recurse()' language sql;
\set VERBOSITY terse
select infinite_recurse();
+

--ZRyEpB+iJ+qUx0kp--

--cpvLTH7QU4gwfq3S
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFERg7WIB7bNG8LQkwRAilXAJ9R9u0DU1ym0WT5fNesPK 51CSLsiwCfQrIA
knLKON5STu67nUt3EtH5bjo=
=LVNO
-----END PGP SIGNATURE-----

--cpvLTH7QU4gwfq3S--