Re: [BUGS] Bug in window xp

#1

Confirmed here.

What we get is Integer Overflow, on the instruction "idiv esi" in postgres!=
int4div+0x1f. (Per windows debugger.) Same does not happen on Linux.

Tom - hints? ;-) Any idea why this happens on win32 but not linux?

//Magnus

Quote:

-----Original Message-----
From: pgsql-bugs-owner (AT) postgresql (DOT) org=20
[mailto

gsql-bugs-owner (AT) postgresql (DOT) org] On Behalf Of Wang Haiyong
Sent: Wednesday, April 05, 2006 4:34 AM
To: pgsql-bugs (AT) postgresql (DOT) org
Subject: [BUGS] Bug in window xp
=20
Version(8.1.3)
Bug in window xp:
=20=20
C:\Documents and Settings\openbase>pg_ctl start
LOG: database system was shut down at 2006-4-04 15:54:43 =D6=D0=B9=FA=B1=
=EA=D7=BC=CA=B1=BC=E4
LOG: checkpoint record is at 0/38C2E0
LOG: redo record is at 0/38C2E0; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 569; next OID: 24576
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system is ready
LOG: transaction ID wrap limit is 2147484146, limited by=20
database "postgres"
=20=20
C:\Documents and Settings\openbase
C:\Documents and Settings\openbase
C:\Documents and Settings\openbase
C:\Documents and Settings\openbase>psql
Welcome to psql 8.1.3, the PostgreSQL interactive terminal.
=20=20
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
=20=20
openbase=3D# SELECT (-2147483648) / (-1);
LOG: server process (PID 3760) was terminated by signal 21
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
=B7=FE=CE=F1=C6=F7=D2=E2=CD=E2=B5=D8=B9=D8=B1=D5=C 1=CB=C1=AA=BD=D3
=D5=E2=D6=D6=CF=D6=CF=F3=CD=A8=B3=A3=D2=E2=CE=B6=D 7=C5=B7=FE=CE=
=F1=C6=F7=D4=DA=B4=A6=C0=ED=C7=EB=C7=F3=D6=AE=C7=B 0
=BB=F2=D5=DF=D5=FD=D4=DA=B4=A6=C0=ED=C7=EB=C7=F3=B 5=C4=CA=B1=BA=F2=D2=E2=
=CD=E2=D6=D0=D6=B9
=D3=EB=B7=FE=CE=F1=C6=F7=B5=C4=C1=AA=BD=D3=D2=D1=B 6=AA=CA=A7. =B3=A2=CA=
=D4=D6=D8=D6=C3: LOG: database system was interrupted at=20
2006-0-05 08:39:56 =D6=D0=B9=FA=B1=EA=D7=BC=CA=B1=BC=E4
LOG: checkpoint record is at 0/38C2E0
LOG: redo record is at 0/38C2E0; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 569; next OID: 24576
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system was not properly shut down; automatic=20
recovery in progres
=20=20
FATAL: the database system is starting up
=CA=A7=B0=DC.
!> LOG: record with zero length at 0/38C328
LOG: redo is not required
LOG: database system is ready
LOG: transaction ID wrap limit is 2147484146, limited by=20
database "postgres"
=20=20
=20=20
=20
=CD=F5=BA=A3=D3=C0
=B6=AB=C8=ED=BC=AF=CD=C5=C8=ED=BC=FE=B2=FA=C6=B7=C A=C2=D2=B5=B2=BF
=20=20
=B5=D8=D6=B7=A3=BA=C9=F2=D1=F4=CA=D0=BB=EB=C4=CF=B 8=DF=D0=C2=BC=BC=CA=F5=
=B2=FA=D2=B5=BF=AA=B7=A2=C7=F8=B6=AB=C8=ED=C8=ED=B C=FE=D4=B0 A1=D7=F9
=D3=CA=B1=E0=A3=BA110179
=B5=E7=BB=B0=A3=BA024=A3=AD83661905
=B9=AB=CB=BE=CD=F8=D6=B7=A3=BAwww.neusoft.com
=20
________________________________
=20
Confidentiality Notice: The information contained in this=20
e-mail and any accompanying attachment(s) is intended only=20
for the use of the intended recipient and may be confidential=20
and/or privileged of Neusoft Group Ltd., its subsidiaries=20
and/or its affiliates. If any reader of this communication is=20
not the intended recipient, unauthorized use, forwarding,=20
printing, storing, disclosure or copying is strictly=20
prohibited, and may be unlawful. If you have received this=20
communication in error, please immediately notify the sender=20
by return e-mail, and delete the original message and all=20
copies from your system. Thank you.=20
________________________________
=20
=20

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

#2

"Magnus Hagander" <mha (AT) sollentuna (DOT) net> writes:

Quote:

What we get is Integer Overflow, on the instruction "idiv esi" in postgres!int4div+0x1f. (Per windows debugger.) Same does not happen on Linux.

Tom - hints? ;-) Any idea why this happens on win32 but not linux?

Perhaps there's some process-wide setting that enables or disables that?

It seems fairly inconsistent to have a machine trap on divide overflow
when it doesn't on any other integer overflow, so I'd rather turn it off
than work around it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

#3

This is a multi-part message in MIME format.

------_=_NextPart_001_01C65AF8.DD5F1AB6
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Quote:

"Magnus Hagander" <mha (AT) sollentuna (DOT) net> writes:
What we get is Integer Overflow, on the instruction "idiv=20
esi" in postgres!int4div+0x1f. (Per windows debugger.) Same=20
does not happen on Linux.
=20
Tom - hints? ;-) Any idea why this happens on win32 but not linux?
=20
Perhaps there's some process-wide setting that enables or=20
disables that?
=20
It seems fairly inconsistent to have a machine trap on divide=20
overflow when it doesn't on any other integer overflow, so=20
I'd rather turn it off than work around it.

Been doing some more research on this one. Seems that since this is a
hardware exception, there is no way to ignore it :-( What you can do is
create a structured exception filter that will get called, and can
detect it. At this point, you can "do your magic" and then have the
processor re-execute the instruction that failed - with any registers
modified per your preference.

So what we'd do in this case is, from what I can tell, to manipulate EIP
to make it point past the exception itself and then return
EXCEPTION_CONTINUE_EXECUTION.

However, this seems like a lot more of a kludge than putting in a check
in the code. And we'd need to know it's *always* safe to advance EIP
once on integer overflows, which I certainly can't speak for :-)

(If we just say continue execution, the program gets stuck in an
infinite loop because the exception just happens over and over again -
no surprise there)

So given that, I think I'm for putting in the check in the code.

As a sidenote, I noticed I never followed through on an old discussion
about crashing. Right now, when a postgres backend crashes it pops up a
GUI window to let the user know so. Only when the user has dismissed
this window does the postmaster notice. Attached patch changes this so
we don't provide GUI notification on crash, but instead just crashes and
let the postmaster deal with it.=20

//Magnus

------_=_NextPart_001_01C65AF8.DD5F1AB6
Content-Type: application/octet-stream;
name="gpf_box.patch"
Content-Transfer-Encoding: base64
Content-Description: gpf_box.patch
Content-Disposition: attachment;
filename="gpf_box.patch"

SW5kZXg6IHNyYy9iYWNrZW5kL21haW4vbWFpbi5jDQo9PT09PT 09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT 09PT09PT09
PT09PT09PT09DQpSQ1MgZmlsZTogL3Byb2plY3RzL2N2c3Jvb3 QvcGdzcWwv
c3JjL2JhY2tlbmQvbWFpbi9tYWluLmMsdg0KcmV0cmlldmluZy ByZXZpc2lv
biAxLjk2LjIuMw0KZGlmZiAtYyAtcjEuOTYuMi4zIG1haW4uYw 0KKioqIHNy
Yy9iYWNrZW5kL21haW4vbWFpbi5jCTEgRmViIDIwMDYgMDA6Mz I6MDUgLTAw
MDAJMS45Ni4yLjMNCi0tLSBzcmMvYmFja2VuZC9tYWluL21haW 4uYwk4IEFw
ciAyMDA2IDEwOjIyOjQwIC0wMDAwDQoqKioqKioqKioqKioqKi oNCioqKiAx
MTcsMTIyICoqKioNCi0tLSAxMTcsMTI1IC0tLS0NCiAgCQkJCQ kJIGFyZ3Zb
MF0sIGVycik7DQogIAkJCWV4aXQoMSk7DQogIAkJfQ0KKyANCi sgICAgICAg
ICAvKiBJbiBjYXNlIG9mIGdlbmVyYWwgcHJvdGVjdGlvbiBmYX VsdCwgZG9u
J3Qgc2hvdyBHVUkgcG9wdXAgYm94ICovDQorICAgICAgICAgU2 V0RXJyb3JN
b2RlKFNFTV9GQUlMQ1JJVElDQUxFUlJPUlMgfCBTRU1fTk9HUE ZBVUxURVJS
T1JCT1gpOw0KICAJfQ0KICAjZW5kaWYNCiAgDQo=

------_=_NextPart_001_01C65AF8.DD5F1AB6
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0

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

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

------_=_NextPart_001_01C65AF8.DD5F1AB6--

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Re: [BUGS] Bug in window xp

mailing.database.pgsql-bugs mailing.database.pgsql-bugs

Re: [BUGS] Bug in window xp - 04-07-2006 , 04:14 AM

Re: [BUGS] Bug in window xp - 04-07-2006 , 09:18 AM

Re: [BUGS] Bug in window xp - 04-08-2006 , 05:41 AM