Thread: Bug in window xp
VmVyc2lvbig4LjEuMykNCkJ1ZyBpbiB3aW5kb3cgeHA6DQoNCkM6XERvY3Vt ZW50cyBhbmQgU2V0dGluZ3Ncb3BlbmJhc2U+cGdfY3RsIHN0YXJ0DQpMT0c6 ICBkYXRhYmFzZSBzeXN0ZW0gd2FzIHNodXQgZG93biBhdCAyMDA2LTQtMDQg MTU6NTQ6NDMg1tC5+rHq17zKsbzkDQpMT0c6ICBjaGVja3BvaW50IHJlY29y ZCBpcyBhdCAwLzM4QzJFMA0KTE9HOiAgcmVkbyByZWNvcmQgaXMgYXQgMC8z OEMyRTA7IHVuZG8gcmVjb3JkIGlzIGF0IDAvMDsgc2h1dGRvd24gVFJVRQ0K TE9HOiAgbmV4dCB0cmFuc2FjdGlvbiBJRDogNTY5OyBuZXh0IE9JRDogMjQ1 NzYNCkxPRzogIG5leHQgTXVsdGlYYWN0SWQ6IDE7IG5leHQgTXVsdGlYYWN0 T2Zmc2V0OiAwDQpMT0c6ICBkYXRhYmFzZSBzeXN0ZW0gaXMgcmVhZHkNCkxP RzogIHRyYW5zYWN0aW9uIElEIHdyYXAgbGltaXQgaXMgMjE0NzQ4NDE0Niwg bGltaXRlZCBieSBkYXRhYmFzZSAicG9zdGdyZXMiDQoNCkM6XERvY3VtZW50 cyBhbmQgU2V0dGluZ3Ncb3BlbmJhc2U+DQpDOlxEb2N1bWVudHMgYW5kIFNl dHRpbmdzXG9wZW5iYXNlPg0KQzpcRG9jdW1lbnRzIGFuZCBTZXR0aW5nc1xv cGVuYmFzZT4NCkM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3Ncb3BlbmJhc2U+ cHNxbA0KV2VsY29tZSB0byBwc3FsIDguMS4zLCB0aGUgUG9zdGdyZVNRTCBp bnRlcmFjdGl2ZSB0ZXJtaW5hbC4NCg0KVHlwZTogIFxjb3B5cmlnaHQgZm9y IGRpc3RyaWJ1dGlvbiB0ZXJtcw0KICAgICAgIFxoIGZvciBoZWxwIHdpdGgg U1FMIGNvbW1hbmRzDQogICAgICAgXD8gZm9yIGhlbHAgd2l0aCBwc3FsIGNv bW1hbmRzDQogICAgICAgXGcgb3IgdGVybWluYXRlIHdpdGggc2VtaWNvbG9u IHRvIGV4ZWN1dGUgcXVlcnkNCiAgICAgICBccSB0byBxdWl0DQoNCm9wZW5i YXNlPSMgU0VMRUNUICgtMjE0NzQ4MzY0OCkgLyAoLTEpOw0KTE9HOiAgc2Vy dmVyIHByb2Nlc3MgKFBJRCAzNzYwKSB3YXMgdGVybWluYXRlZCBieSBzaWdu YWwgMjENCkxPRzogIHRlcm1pbmF0aW5nIGFueSBvdGhlciBhY3RpdmUgc2Vy dmVyIHByb2Nlc3Nlcw0KTE9HOiAgYWxsIHNlcnZlciBwcm9jZXNzZXMgdGVy bWluYXRlZDsgcmVpbml0aWFsaXppbmcNCrf+zvHG99LizeK12LnYsdXBy8Gq vdMNCiAgICAgICAg1eLW1s/Wz/PNqLOj0uLOttfFt/7O8cb31Nq0psDtx+vH 89aux7ANCrvy1d/V/dTatKbA7cfrx/O1xMqxuvLS4s3i1tDWuQ0K0+u3/s7x xve1xMGqvdPS0baqyqcuILOiytTW2NbDOiBMT0c6ICBkYXRhYmFzZSBzeXN0 ZW0gd2FzIGludGVycnVwdGVkIGF0IDIwMDYtMC0wNSAwODozOTo1NiDW0Ln6 serXvMqxvOQNCkxPRzogIGNoZWNrcG9pbnQgcmVjb3JkIGlzIGF0IDAvMzhD MkUwDQpMT0c6ICByZWRvIHJlY29yZCBpcyBhdCAwLzM4QzJFMDsgdW5kbyBy ZWNvcmQgaXMgYXQgMC8wOyBzaHV0ZG93biBUUlVFDQpMT0c6ICBuZXh0IHRy YW5zYWN0aW9uIElEOiA1Njk7IG5leHQgT0lEOiAyNDU3Ng0KTE9HOiAgbmV4 dCBNdWx0aVhhY3RJZDogMTsgbmV4dCBNdWx0aVhhY3RPZmZzZXQ6IDANCkxP RzogIGRhdGFiYXNlIHN5c3RlbSB3YXMgbm90IHByb3Blcmx5IHNodXQgZG93 bjsgYXV0b21hdGljIHJlY292ZXJ5IGluIHByb2dyZXMNCg0KRkFUQUw6ICB0 aGUgZGF0YWJhc2Ugc3lzdGVtIGlzIHN0YXJ0aW5nIHVwDQrKp7DcLg0KIT4g TE9HOiAgcmVjb3JkIHdpdGggemVybyBsZW5ndGggYXQgMC8zOEMzMjgNCkxP RzogIHJlZG8gaXMgbm90IHJlcXVpcmVkDQpMT0c6ICBkYXRhYmFzZSBzeXN0 ZW0gaXMgcmVhZHkNCkxPRzogIHRyYW5zYWN0aW9uIElEIHdyYXAgbGltaXQg aXMgMjE0NzQ4NDE0NiwgbGltaXRlZCBieSBkYXRhYmFzZSAicG9zdGdyZXMi DQoNCg0KDQrN9bqj08ANCraryO28r83FyO28/rL6xrfKwtK1sr8NCiANCrXY 1rejusny0fTK0LvrxM+439DCvLzK9bL60rW/qreix/i2q8jtyO28/tSwIEEx 1/kNCtPKseCjujExMDE3OQ0Ktee7sKO6MDI0o604MzY2MTkwNQ0KuavLvs34 1rejund3dy5uZXVzb2Z0LmNvbQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpDb25maWRlbnRpYWxpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWls IGFuZCBhbnkgYWNjb21wYW55aW5nIGF0dGFjaG1lbnQocykgaXMgaW50ZW5k ZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IGFuZCBtYXkgYmUgY29uZmlkZW50aWFsIGFuZC9vciBwcml2aWxlZ2VkIG9m IE5ldXNvZnQgR3JvdXAgTHRkLiwgaXRzIHN1YnNpZGlhcmllcyBhbmQvb3Ig aXRzIGFmZmlsaWF0ZXMuIElmIGFueSByZWFkZXIgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB1bmF1dGhv cml6ZWQgdXNlLCBmb3J3YXJkaW5nLCBwcmludGluZywgc3RvcmluZywgZGlz Y2xvc3VyZSBvciBjb3B5aW5nIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIGFu ZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg Y29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5v dGlmeSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIGFuZCBkZWxldGUg dGhlIG9yaWdpbmFsIG1lc3NhZ2UgYW5kIGFsbCBjb3BpZXMgZnJvbSB5b3Vy IHN5c3RlbS4gVGhhbmsgeW91LiAKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCg==
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 > -----Original Message----- > From: pgsql-bugs-owner@postgresql.org=20 > [mailto:pgsql-bugs-owner@postgresql.org] On Behalf Of Wang Haiyong > Sent: Wednesday, April 05, 2006 4:34 AM > To: pgsql-bugs@postgresql.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=C1=CB=C1=AA=BD=D3 > =D5=E2=D6=D6=CF=D6=CF=F3=CD=A8=B3=A3=D2=E2=CE=B6=D7=C5=B7=FE=CE= =F1=C6=F7=D4=DA=B4=A6=C0=ED=C7=EB=C7=F3=D6=AE=C7=B0 > =BB=F2=D5=DF=D5=FD=D4=DA=B4=A6=C0=ED=C7=EB=C7=F3=B5=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=B6=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=CA=C2=D2=B5=B2=BF >=20=20 > =B5=D8=D6=B7=A3=BA=C9=F2=D1=F4=CA=D0=BB=EB=C4=CF=B8=DF=D0=C2=BC=BC=CA=F5= =B2=FA=D2=B5=BF=AA=B7=A2=C7=F8=B6=AB=C8=ED=C8=ED=BC=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
"Magnus Hagander" <mha@sollentuna.net> writes:
> What we get is Integer Overflow, on the instruction "idiv esi" in postgres!int4div+0x1f. (Per windows debugger.) Same
doesnot 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
> "Magnus Hagander" <mha@sollentuna.net> writes: > > 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. 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. //Magnus
Attachment
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. > SELECT (-2147483648) / (-1); ERROR: floating-point exception 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@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Martijn van Oosterhout <kleptog@svana.org> writes:
> Re: SIGFPE on integer divide.
> This signal does appear on linux also.
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:
> A simple C program shows the same. Why isn't it being caught on
> windows?
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
On Sat, Apr 08, 2006 at 12:27:19PM -0400, Tom Lane wrote: > Hmm, it seems to depend on the hardware you're using. I just tried it > on four different machines: <no consistancy whatsoever> > > A simple C program shows the same. Why isn't it being caught on > > windows? >=20 > 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. 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@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Is anyone working on this? --------------------------------------------------------------------------- Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Sat, Apr 08, 2006 at 12:27:19PM -0400, Tom Lane wrote: > > Hmm, it seems to depend on the hardware you're using. I just tried it > > on four different machines: > > <no consistancy whatsoever> > > > > A simple C program shows the same. Why isn't it being caught on > > > windows? > > > > 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. > > 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, > -- > Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > > tool for doing 5% of the work and then sitting around waiting for someone > > else to do the other 95% so you can sue them. -- End of PGP section, PGP failed! -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Martijn van Oosterhout <kleptog@svana.org> writes:
> Not that I know of. However, the first step is to add this regression
> test for SIGFPE [-patches CCed].
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
Martijn van Oosterhout <kleptog@svana.org> writes:
> 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?
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
[Re: Uncaught exception when dividing integers] On Tue, Apr 18, 2006 at 10:50:24PM -0400, Bruce Momjian wrote: > > Is anyone working on this? 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, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment
On Wed, Apr 19, 2006 at 10:15:54AM -0400, Tom Lane wrote: > Martijn van Oosterhout <kleptog@svana.org> writes: > > Not that I know of. However, the first step is to add this regression > > test for SIGFPE [-patches CCed]. > > This seems completely pointless. The question is not about whether the > SIGFPE catcher works when fired, it's about what conditions trigger it. 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-bugs/2006-04/msg00091.php Otherwise we should just fix int4div. -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.