Win32 WEXITSTATUS too simplistic

Tom Lane wrote:

win32.h says

/*
* Signal stuff
* WIN32 doesn't have wait(), so the return value for children
* is simply the return value specified by the child, without
* any additional information on whether the child terminated
* on its own or via a signal. These macros are also used
* to interpret the return value of system().
*/
#define WEXITSTATUS(w) (w)
#define WIFEXITED(w) (true)
#define WIFSIGNALED(w) (false)
#define WTERMSIG(w) (0)

I think this supposition has been pretty much proven false by recent
reports of silly "exit code" numbers from Win32 users, as for instance
here
http://archives.postgresql.org/pgsql-bugs/2006-12/msg00163.php
where the postmaster reports
server process exited with exit code -1073741819
from what I suspect is really the equivalent of a SIGSEGV trap,
ie, attempted access to already-deallocated memory. My calculator
says the above is equivalent to hex C0000005, and I say that this
makes it pretty clear that *some* parts of Windows put flag bits into
the process exit code. Anyone want to run down what we should really
be using instead of the above macros?

The exit code is apparently what is reported from GetExitCodeProcess().
For info on that see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getexitcodeprocess.asp

I think we are possibly seeing the third case, i.e. the code from an
unhandled exception. I haven't managed to find an API to handle them
though ...

cheers

andrew

"Andrew Dunstan" <andrew@dunslane.net> writes:

Tom Lane wrote:

Anyone want to run down what we should really
be using instead of the above macros?

The exit code is apparently what is reported from GetExitCodeProcess().
For info on that see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getexitcodeprocess.asp

I think we are possibly seeing the third case, i.e. the code from an
unhandled exception. I haven't managed to find an API to handle them
though ...

Right ... but I don't think we want to "handle the exception". The
right question to be asking is "what is the encoding of these 'exception
values' it's talking about?"

regards, tom lane

Tom Lane wrote:

"Andrew Dunstan" <andrew@dunslane.net> writes:

Tom Lane wrote:

Anyone want to run down what we should really
be using instead of the above macros?

The exit code is apparently what is reported from GetExitCodeProcess().
For info on that see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getexitcodeprocess.asp

I think we are possibly seeing the third case, i.e. the code from an
unhandled exception. I haven't managed to find an API to handle them
though ...

Right ... but I don't think we want to "handle the exception". The
right question to be asking is "what is the encoding of these 'exception
values' it's talking about?"

Yes, sorry for my loose expression. That's what I meant - I didn't find an
API that would translate the exception values.

cheers

andrew

Tom Lane <tgl@sss.pgh.pa.us> wrote:

server process exited with exit code -1073741819
from what I suspect is really the equivalent of a SIGSEGV trap,
ie, attempted access to already-deallocated memory. My calculator
says the above is equivalent to hex C0000005, and I say that this
makes it pretty clear that *some* parts of Windows put flag bits into
the process exit code. Anyone want to run down what we should really
be using instead of the above macros?

C0000005 equals to EXCEPTION_ACCESS_VIOLATION. The value returned by
GetExceptionCode() seems to be the exit code in unhandeled exception cases.

AFAICS, all EXCEPTION_xxx (or STATUS_xxx) values are defined as 0xCxxxxxxx.
I think we can use the second high bit to distinguish exit by exception
from normal exits.

#define WEXITSTATUS(w) ((int) ((w) & 0x40000000))
#define WIFEXITED(w) ((w) & 0x40000000) == 0)
#define WIFSIGNALED(w) ((w) & 0x40000000) != 0)
#define WTERMSIG(w) (w) // or ((w) & 0x3FFFFFFF)

However, it comes from reverse engineering of the headers of Windows.
I cannot find any official documentation.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

I did some research on this, and found a nice Win32 list of STATUS_
error values. Looking at the list, I think the non-exit() return values
are much larger than just the second high bit.

I am proposing the attached patch, which basically has all system()
return values < 0x100 as exit() calls, and everything above that as a
signal exits. I also think it is too risky to backpatch to 8.2.X.

Also, should we print Win32 WTERMSIG() values as hex because they are so
large? I have added that to the patch.

---------------------------------------------------------------------------

ITAGAKI Takahiro wrote:

Tom Lane <tgl@sss.pgh.pa.us> wrote:

server process exited with exit code -1073741819
from what I suspect is really the equivalent of a SIGSEGV trap,
ie, attempted access to already-deallocated memory. My calculator
says the above is equivalent to hex C0000005, and I say that this
makes it pretty clear that *some* parts of Windows put flag bits into
the process exit code. Anyone want to run down what we should really
be using instead of the above macros?

C0000005 equals to EXCEPTION_ACCESS_VIOLATION. The value returned by
GetExceptionCode() seems to be the exit code in unhandeled exception cases.

AFAICS, all EXCEPTION_xxx (or STATUS_xxx) values are defined as 0xCxxxxxxx.
I think we can use the second high bit to distinguish exit by exception
from normal exits.

#define WEXITSTATUS(w) ((int) ((w) & 0x40000000))
#define WIFEXITED(w) ((w) & 0x40000000) == 0)
#define WIFSIGNALED(w) ((w) & 0x40000000) != 0)
#define WTERMSIG(w) (w) // or ((w) & 0x3FFFFFFF)

However, it comes from reverse engineering of the headers of Windows.
I cannot find any official documentation.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

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

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

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

I have applied a modified version of this patch. We now print the
exception value in hex, and give a URL where the exception can be looked
up.

---------------------------------------------------------------------------

Bruce Momjian wrote:

I did some research on this, and found a nice Win32 list of STATUS_
error values. Looking at the list, I think the non-exit() return values
are much larger than just the second high bit.

I am proposing the attached patch, which basically has all system()
return values < 0x100 as exit() calls, and everything above that as a
signal exits. I also think it is too risky to backpatch to 8.2.X.

Also, should we print Win32 WTERMSIG() values as hex because they are so
large? I have added that to the patch.

---------------------------------------------------------------------------

ITAGAKI Takahiro wrote:

Tom Lane <tgl@sss.pgh.pa.us> wrote:

server process exited with exit code -1073741819
from what I suspect is really the equivalent of a SIGSEGV trap,
ie, attempted access to already-deallocated memory. My calculator
says the above is equivalent to hex C0000005, and I say that this
makes it pretty clear that *some* parts of Windows put flag bits into
the process exit code. Anyone want to run down what we should really
be using instead of the above macros?

C0000005 equals to EXCEPTION_ACCESS_VIOLATION. The value returned by
GetExceptionCode() seems to be the exit code in unhandeled exception cases.

AFAICS, all EXCEPTION_xxx (or STATUS_xxx) values are defined as 0xCxxxxxxx.
I think we can use the second high bit to distinguish exit by exception
from normal exits.

#define WEXITSTATUS(w) ((int) ((w) & 0x40000000))
#define WIFEXITED(w) ((w) & 0x40000000) == 0)
#define WIFSIGNALED(w) ((w) & 0x40000000) != 0)
#define WTERMSIG(w) (w) // or ((w) & 0x3FFFFFFF)

However, it comes from reverse engineering of the headers of Windows.
I cannot find any official documentation.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

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

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

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

I have applied a modified version of this patch. We now print the
exception value in hex, and give a URL where the exception can be looked
up.

Humm, wouldn't it be more appropriate to put the URL in a errhint()
instead?

+ 		ereport(lev,
+ 
+ 		/*------
+ 		  translator: %s is a noun phrase describing a child process, such as
+ 		  "server process" */
+ 				(errmsg("%s (PID %d) was terminated by exception %X\nSee http://source.winehq.org/source/include/ntstatus.h for a description\nof the hex value.",
+ 						procname, pid, WTERMSIG(exitstatus))));
+ #endif

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:

Bruce Momjian wrote:

I have applied a modified version of this patch. We now print the
exception value in hex, and give a URL where the exception can be looked
up.

Humm, wouldn't it be more appropriate to put the URL in a errhint()
instead?

+ 		ereport(lev,
+ 
+ 		/*------
+ 		  translator: %s is a noun phrase describing a child process, such as
+ 		  "server process" */
+ 				(errmsg("%s (PID %d) was terminated by exception %X\nSee http://source.winehq.org/source/include/ntstatus.h for a description\nof the hex value.",
+ 						procname, pid, WTERMSIG(exitstatus))));
+ #endif

Oops, forgot to mention that detail. We are using log_error() in one
case, and ereport() in another. Let me do the hint in the report case,
but I have to leave the log_error case alone because it takes only three
arguments.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Alvaro Herrera <alvherre@commandprompt.com> writes:

Bruce Momjian wrote:

I have applied a modified version of this patch. We now print the
exception value in hex, and give a URL where the exception can be looked
up.

Humm, wouldn't it be more appropriate to put the URL in a errhint()
instead?

It should not be there at all. Do you see URLs in any of our other
error messages?

regards, tom lane

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Bruce Momjian wrote:

I have applied a modified version of this patch. We now print the
exception value in hex, and give a URL where the exception can be looked
up.

Humm, wouldn't it be more appropriate to put the URL in a errhint()
instead?

It should not be there at all. Do you see URLs in any of our other
error messages?

Sure, ideally, but how else can we give information about that hex
value?

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:

Tom Lane wrote:

It should not be there at all. Do you see URLs in any of our other
error messages?

Sure, ideally, but how else can we give information about that hex
value?

It's not the responsibility of that error message to tell someone to
go look up the error number in Microsoft documentation. If they're
clueful enough to make any sense of the number beyond the strerror
translation we already provide, then they already know where to look.

Even if it were the responsibility of the error message to suggest this,
a URL seems far too transient.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Tom Lane wrote:

It should not be there at all. Do you see URLs in any of our other
error messages?

Sure, ideally, but how else can we give information about that hex
value?

It's not the responsibility of that error message to tell someone to
go look up the error number in Microsoft documentation. If they're
clueful enough to make any sense of the number beyond the strerror
translation we already provide, then they already know where to look.

Well, it took me like 25 minutes to find that list, so it isn't obvious.
Search for STATUS_CARDBUS_NOT_SUPPORTED, and you get only 75 hits on
Google, and our URL is #7. One idea Andrew Dunstan had was to print
descriptions for the most popular values. I asked him to give it a try
once I applied this patch.

Even if it were the responsibility of the error message to suggest this,
a URL seems far too transient.

It is a URL to the Wine CVS repository, so I assume it will be around for
a while. One thing we could do is copy that file to a URL on our web
site and point error messages to that. We could put the file in our CVS
and point to that too.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

bruce wrote:

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Bruce Momjian wrote:

OK, maybe /doc or src/tools. A more radical approach would be to put
the list in our documentation, or have initdb install it.

Why not put it in techdocs or some such?

I think we've learned by now that putting copies of other peoples' code
in our tree isn't such a hot idea; what is going to cause it to be
updated when things change? How do you know the values are even the
same across all the Windows versions we support?

Basically this whole idea is misconceived. Just print the number and
have done.

And how do people interpret that number?

Ah, I found something:

http://support.microsoft.com/kb/259693

Someone on IRC says that is kernel mode only, and is looking for a
user-mode version, so we would be able to print out a meaningful message
rather than a hex value that has to be looked up.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

OK, I have tested on MinGW and found I can use FormatMessage() to print
a description for all ERROR* system() failures, rather than print a hex
value. This removes the need for a URL or lookup of hex values.
Attached and applied.

---------------------------------------------------------------------------

Bruce Momjian wrote:

bruce wrote:

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Bruce Momjian wrote:

OK, maybe /doc or src/tools. A more radical approach would be to put
the list in our documentation, or have initdb install it.

Why not put it in techdocs or some such?

I think we've learned by now that putting copies of other peoples' code
in our tree isn't such a hot idea; what is going to cause it to be
updated when things change? How do you know the values are even the
same across all the Windows versions we support?

Basically this whole idea is misconceived. Just print the number and
have done.

And how do people interpret that number?

Ah, I found something:

http://support.microsoft.com/kb/259693

Someone on IRC says that is kernel mode only, and is looking for a
user-mode version, so we would be able to print out a meaningful message
rather than a hex value that has to be looked up.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

From: "Bruce Momjian" <bruce@momjian.us>

OK, I have tested on MinGW and found I can use FormatMessage() to

print

a description for all ERROR* system() failures, rather than print a

hex

value. This removes the need for a URL or lookup of hex values.
Attached and applied.

Excuse me if I'm misunderstanding, but I'm afraid you are mixing up
Win32 error codes and exception codes. I saw the following fragment
in your patch:

! * On MinGW, system() returns STATUS_* values. MSVC might be
! * different. To test, create a binary that does *(NULL), and
! * then create a second binary that calls it via system(),
! * and check the return value of system(). On MinGW, it is
! * 0xC0000005 == STATUS_ACCESS_VIOLATION, and 0x5 is a value
! * FormatMessage() can look up. GetLastError() does not work;
! * always zero.

Exception codes and error codes are different and not related. In the
above test, 0xC0000005 is an "exception code". On the other hand, what
FormatMessage() accepts is an error code. Error codes can't derived
from exception codes. Stripping off 0xC bit from an exception code
does not convert it to an error code.
I suspect the reason why you misunderstood is that the descriptions
are similar:
the description for exception 0xC0000005 (STATUS_ACCESS_VIOLATION) is
"access violation" (though the text can't be obtained). This is
caused by an illegal memory access. This is a program bug.
The description for 0x5 (ERROR_ACCESS_DENIED) is "Access is denied."
This is caused by permission checks. This is not a bug, and can
happen normally.

Try "1.0 / 0.0" (devide by zero) instead of (*NULL). What would your
patch display? The exception would be 0xC000008E
(STATUS_FLOAT_DIVIDE_BY_ZERO), I think. 0x8E is ERROR_BUSY_DRIVE.

Takayuki Tsunakawa wrote:

From: "Bruce Momjian" <bruce@momjian.us>

OK, I have tested on MinGW and found I can use FormatMessage() to

print

a description for all ERROR* system() failures, rather than print a

hex

value. This removes the need for a URL or lookup of hex values.
Attached and applied.

Excuse me if I'm misunderstanding, but I'm afraid you are mixing up
Win32 error codes and exception codes. I saw the following fragment
in your patch:

! * On MinGW, system() returns STATUS_* values. MSVC might be
! * different. To test, create a binary that does *(NULL), and
! * then create a second binary that calls it via system(),
! * and check the return value of system(). On MinGW, it is
! * 0xC0000005 == STATUS_ACCESS_VIOLATION, and 0x5 is a value
! * FormatMessage() can look up. GetLastError() does not work;
! * always zero.

Exception codes and error codes are different and not related. In the
above test, 0xC0000005 is an "exception code". On the other hand, what
FormatMessage() accepts is an error code. Error codes can't derived
from exception codes. Stripping off 0xC bit from an exception code
does not convert it to an error code.
I suspect the reason why you misunderstood is that the descriptions
are similar:
the description for exception 0xC0000005 (STATUS_ACCESS_VIOLATION) is
"access violation" (though the text can't be obtained). This is
caused by an illegal memory access. This is a program bug.
The description for 0x5 (ERROR_ACCESS_DENIED) is "Access is denied."
This is caused by permission checks. This is not a bug, and can
happen normally.

Try "1.0 / 0.0" (devide by zero) instead of (*NULL). What would your
patch display? The exception would be 0xC000008E
(STATUS_FLOAT_DIVIDE_BY_ZERO), I think. 0x8E is ERROR_BUSY_DRIVE.

Yes, you are 100% correct that I had exceptions and errors confused. I
have backed out the patch that used FormatMessage(), and instead of
using a URL, the message is now:

child process was terminated by exception %X
See /include/ntstatus.h for a description of the hex value.

When I search for /include/ntstatus.h, I get the Wine page first, so
hopefully we can mark this item as completed.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

From: "Bruce Momjian" <bruce@momjian.us>
Yes, you are 100% correct that I had exceptions and errors confused.
I

have backed out the patch that used FormatMessage(), and instead of
using a URL, the message is now:

child process was terminated by exception %X
See /include/ntstatus.h for a description of the hex value.

When I search for /include/ntstatus.h, I get the Wine page first, so
hopefully we can mark this item as completed.

Thank you, Bruce-san. I agree.

----- Original Message -----
From: "Bruce Momjian" <bruce@momjian.us>
To: "Takayuki Tsunakawa" <tsunakawa.takay@jp.fujitsu.com>
Cc: "PostgreSQL-patches" <pgsql-patches@postgresql.org>; "Tom Lane"
<tgl@sss.pgh.pa.us>; "Alvaro Herrera" <alvherre@commandprompt.com>;
"Magnus Hagander" <magnus@hagander.net>; "ITAGAKI Takahiro"
<itagaki.takahiro@oss.ntt.co.jp>
Sent: Tuesday, January 23, 2007 12:35 PM
Subject: Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too

Takayuki Tsunakawa wrote:

From: "Bruce Momjian" <bruce@momjian.us>

OK, I have tested on MinGW and found I can use FormatMessage() to

print

a description for all ERROR* system() failures, rather than print

a

hex

value. This removes the need for a URL or lookup of hex values.
Attached and applied.

Excuse me if I'm misunderstanding, but I'm afraid you are mixing up
Win32 error codes and exception codes. I saw the following

fragment

in your patch:

! * On MinGW, system() returns STATUS_* values. MSVC might be
! * different. To test, create a binary that does *(NULL), and
! * then create a second binary that calls it via system(),
! * and check the return value of system(). On MinGW, it is
! * 0xC0000005 == STATUS_ACCESS_VIOLATION, and 0x5 is a value
! * FormatMessage() can look up. GetLastError() does not work;
! * always zero.

Exception codes and error codes are different and not related. In

the

above test, 0xC0000005 is an "exception code". On the other hand,

what

FormatMessage() accepts is an error code. Error codes can't

derived

from exception codes. Stripping off 0xC bit from an exception code
does not convert it to an error code.
I suspect the reason why you misunderstood is that the descriptions
are similar:
the description for exception 0xC0000005 (STATUS_ACCESS_VIOLATION)

is

"access violation" (though the text can't be obtained). This is
caused by an illegal memory access. This is a program bug.
The description for 0x5 (ERROR_ACCESS_DENIED) is "Access is

denied."

This is caused by permission checks. This is not a bug, and can
happen normally.

Try "1.0 / 0.0" (devide by zero) instead of (*NULL). What would

your

patch display? The exception would be 0xC000008E
(STATUS_FLOAT_DIVIDE_BY_ZERO), I think. 0x8E is ERROR_BUSY_DRIVE.

Yes, you are 100% correct that I had exceptions and errors confused.

I

have backed out the patch that used FormatMessage(), and instead of
using a URL, the message is now:

child process was terminated by exception %X
See /include/ntstatus.h for a description of the hex value.

When I search for /include/ntstatus.h, I get the Wine page first, so
hopefully we can mark this item as completed.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of

broadcast)---------------------------

Takayuki Tsunakawa wrote:

From: "Bruce Momjian" <bruce@momjian.us>
Yes, you are 100% correct that I had exceptions and errors confused.
I

have backed out the patch that used FormatMessage(), and instead of
using a URL, the message is now:

child process was terminated by exception %X
See /include/ntstatus.h for a description of the hex value.

When I search for /include/ntstatus.h, I get the Wine page first, so
hopefully we can mark this item as completed.

Thank you, Bruce-san. I agree.

The Win32 port has always been done in small steps, sometimes to the
left or right, but eventually forward.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

Takayuki Tsunakawa wrote:

From: "Bruce Momjian" <bruce@momjian.us>
Yes, you are 100% correct that I had exceptions and errors confused.
I

have backed out the patch that used FormatMessage(), and instead of
using a URL, the message is now:

child process was terminated by exception %X
See /include/ntstatus.h for a description of the hex value.

When I search for /include/ntstatus.h, I get the Wine page first, so
hopefully we can mark this item as completed.

Thank you, Bruce-san. I agree.

The Win32 port has always been done in small steps, sometimes to the
left or right, but eventually forward.

He feints to the left, he feints to the right, he ducks and POW!

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

On Mon, Jan 22, 2007 at 10:35:11PM -0500, Bruce Momjian wrote:

Takayuki Tsunakawa wrote:

From: "Bruce Momjian" <bruce@momjian.us>

OK, I have tested on MinGW and found I can use FormatMessage() to

print

a description for all ERROR* system() failures, rather than print a

hex

value. This removes the need for a URL or lookup of hex values.
Attached and applied.

Excuse me if I'm misunderstanding, but I'm afraid you are mixing up
Win32 error codes and exception codes. I saw the following fragment
in your patch:

! * On MinGW, system() returns STATUS_* values. MSVC might be
! * different. To test, create a binary that does *(NULL), and
! * then create a second binary that calls it via system(),
! * and check the return value of system(). On MinGW, it is
! * 0xC0000005 == STATUS_ACCESS_VIOLATION, and 0x5 is a value
! * FormatMessage() can look up. GetLastError() does not work;
! * always zero.

Exception codes and error codes are different and not related. In the
above test, 0xC0000005 is an "exception code". On the other hand, what
FormatMessage() accepts is an error code. Error codes can't derived
from exception codes. Stripping off 0xC bit from an exception code
does not convert it to an error code.
I suspect the reason why you misunderstood is that the descriptions
are similar:
the description for exception 0xC0000005 (STATUS_ACCESS_VIOLATION) is
"access violation" (though the text can't be obtained). This is
caused by an illegal memory access. This is a program bug.
The description for 0x5 (ERROR_ACCESS_DENIED) is "Access is denied."
This is caused by permission checks. This is not a bug, and can
happen normally.

Try "1.0 / 0.0" (devide by zero) instead of (*NULL). What would your
patch display? The exception would be 0xC000008E
(STATUS_FLOAT_DIVIDE_BY_ZERO), I think. 0x8E is ERROR_BUSY_DRIVE.

Yes, you are 100% correct that I had exceptions and errors confused. I
have backed out the patch that used FormatMessage(), and instead of
using a URL, the message is now:

child process was terminated by exception %X
See /include/ntstatus.h for a description of the hex value.

When I search for /include/ntstatus.h, I get the Wine page first, so
hopefully we can mark this item as completed.

Are you entirely sure that ntstatus.h is where to look? Because per
whatever docs I've found, that contains "device driver errors" and *not*
exception codes.
If it really is, then using FormatMessage is correct - because it's not
an exception value, it'sa DDK error value. AFAIK, that's not the same
as an exception. (Though you have to add the search of ntdll.dll, of
course)

//Magnus

From: "Magnus Hagander" <magnus@hagander.net>

Are you entirely sure that ntstatus.h is where to look? Because per
whatever docs I've found, that contains "device driver errors" and

*not*

exception codes.

Yes, what you are pointing out is correct. winbase.h and winnt.h
should be consulted instead of ntstatus.h. See the the section
"Return Value" in the following page:

http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx

Furthermore, the message is meaningless for users because they can do
nothing with the information. So, I think the message should say
something like

child process was terminated by exception %X
This seems to be a bug of PostgreSQL.
Please report this message with the details of the phynomenon to
PostgreSQL developers.

What do you think?

On Tue, Jan 23, 2007 at 06:50:06PM +0900, Takayuki Tsunakawa wrote:

From: "Magnus Hagander" <magnus@hagander.net>

Are you entirely sure that ntstatus.h is where to look? Because per
whatever docs I've found, that contains "device driver errors" and

*not*

exception codes.

Yes, what you are pointing out is correct. winbase.h and winnt.h
should be consulted instead of ntstatus.h. See the the section
"Return Value" in the following page:

http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx

Furthermore, the message is meaningless for users because they can do
nothing with the information. So, I think the message should say
something like

child process was terminated by exception %X
This seems to be a bug of PostgreSQL.
Please report this message with the details of the phynomenon to
PostgreSQL developers.

What do you think?

I think that's incorrect information to the user :-(
If the child terminates with exit(1), we will then say "child process
was terminated by exception 1. This seems to be a bug", which is clearly
not true.

Unless you know a sure way of determining if the exitcode is a normal
exitcode or an exception code.

//Magnus

Magnus Hagander wrote:

On Tue, Jan 23, 2007 at 06:50:06PM +0900, Takayuki Tsunakawa wrote:

From: "Magnus Hagander" <magnus@hagander.net>

Are you entirely sure that ntstatus.h is where to look? Because per
whatever docs I've found, that contains "device driver errors" and

*not*

exception codes.

Yes, what you are pointing out is correct. winbase.h and winnt.h
should be consulted instead of ntstatus.h. See the the section
"Return Value" in the following page:

http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx

Furthermore, the message is meaningless for users because they can do
nothing with the information. So, I think the message should say
something like

child process was terminated by exception %X
This seems to be a bug of PostgreSQL.
Please report this message with the details of the phynomenon to
PostgreSQL developers.

What do you think?

I think that's incorrect information to the user :-(
If the child terminates with exit(1), we will then say "child process
was terminated by exception 1. This seems to be a bug", which is clearly
not true.

Unless you know a sure way of determining if the exitcode is a normal
exitcode or an exception code.

Current CVS believes values >= 0x100 are non-exit() terminations.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, Jan 23, 2007 at 09:29:19AM -0500, Bruce Momjian wrote:

Magnus Hagander wrote:

On Tue, Jan 23, 2007 at 06:50:06PM +0900, Takayuki Tsunakawa wrote:

From: "Magnus Hagander" <magnus@hagander.net>

Are you entirely sure that ntstatus.h is where to look? Because per
whatever docs I've found, that contains "device driver errors" and

*not*

exception codes.

Yes, what you are pointing out is correct. winbase.h and winnt.h
should be consulted instead of ntstatus.h. See the the section
"Return Value" in the following page:

http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx

Furthermore, the message is meaningless for users because they can do
nothing with the information. So, I think the message should say
something like

child process was terminated by exception %X
This seems to be a bug of PostgreSQL.
Please report this message with the details of the phynomenon to
PostgreSQL developers.

What do you think?

I think that's incorrect information to the user :-(
If the child terminates with exit(1), we will then say "child process
was terminated by exception 1. This seems to be a bug", which is clearly
not true.

Unless you know a sure way of determining if the exitcode is a normal
exitcode or an exception code.

Current CVS believes values >= 0x100 are non-exit() terminations.

Why does it do that :-) That's clearly wrong. There are plenty of
exitcodes > 0x100 that aren't exceptions.

//Magnus

Magnus Hagander wrote:

I think that's incorrect information to the user :-(
If the child terminates with exit(1), we will then say "child process
was terminated by exception 1. This seems to be a bug", which is clearly
not true.

Unless you know a sure way of determining if the exitcode is a normal
exitcode or an exception code.

Current CVS believes values >= 0x100 are non-exit() terminations.

Why does it do that :-) That's clearly wrong. There are plenty of
exitcodes > 0x100 that aren't exceptions.

Please read include/port/win32.h comment section on this and then reply.
We only care about non-exit() exits.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, Jan 23, 2007 at 10:11:58AM -0500, Bruce Momjian wrote:

Magnus Hagander wrote:

I think that's incorrect information to the user :-(
If the child terminates with exit(1), we will then say "child process
was terminated by exception 1. This seems to be a bug", which is clearly
not true.

Unless you know a sure way of determining if the exitcode is a normal
exitcode or an exception code.

Current CVS believes values >= 0x100 are non-exit() terminations.

Why does it do that :-) That's clearly wrong. There are plenty of
exitcodes > 0x100 that aren't exceptions.

Please read include/port/win32.h comment section on this and then reply.
We only care about non-exit() exits.

Right. I did. and exit() can return a lot of error codes > 0x100. For example,
a simple:
int main(int argc, char *argv) {
exit(12345);
}

would break that assumption. (And yes, it works)
exit() takes a 32-bit signed integer, and that's what comes out to the
calling program (verified both with console and standalone program)

The MSDN link referes to the DDK which has to do with driver
development, not userspace. AFAIK, that list is not relevant here, and
I've seen no actual reference so far that it should be used to look up
exit codes.

Now, if we're only caring about exit() from *postgresqls own processes*,
that might hold true. In which case I withdraw that objection as long as
the comment i updated to reflect this ;-) But if we're talking about
exit() in general of any process, then it's simply wrong.

//Magnus

Magnus Hagander wrote:

On Tue, Jan 23, 2007 at 10:11:58AM -0500, Bruce Momjian wrote:

Magnus Hagander wrote:

I think that's incorrect information to the user :-(
If the child terminates with exit(1), we will then say "child process
was terminated by exception 1. This seems to be a bug", which is clearly
not true.

Unless you know a sure way of determining if the exitcode is a normal
exitcode or an exception code.

Current CVS believes values >= 0x100 are non-exit() terminations.

Why does it do that :-) That's clearly wrong. There are plenty of
exitcodes > 0x100 that aren't exceptions.

Please read include/port/win32.h comment section on this and then reply.
We only care about non-exit() exits.

Right. I did. and exit() can return a lot of error codes > 0x100. For example,
a simple:
int main(int argc, char *argv) {
exit(12345);
}

Yes, I know it works, but it can return 0xc0000005 too. I think we have
to be reasonable and say >= 0x100 is probably the OS.

would break that assumption. (And yes, it works)
exit() takes a 32-bit signed integer, and that's what comes out to the
calling program (verified both with console and standalone program)

The MSDN link referes to the DDK which has to do with driver
development, not userspace. AFAIK, that list is not relevant here, and
I've seen no actual reference so far that it should be used to look up
exit codes.

Now, if we're only caring about exit() from *postgresqls own processes*,
that might hold true. In which case I withdraw that objection as long as
the comment i updated to reflect this ;-) But if we're talking about
exit() in general of any process, then it's simply wrong.

Right, that code is only used by the backend and tools.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:

Magnus Hagander wrote:

Now, if we're only caring about exit() from *postgresqls own processes*,
that might hold true. In which case I withdraw that objection as long as
the comment i updated to reflect this ;-) But if we're talking about
exit() in general of any process, then it's simply wrong.

Right, that code is only used by the backend and tools.

We can reasonably assume that no Postgres code will exit() with a value
bigger than 255, because to do so would be unportable.

I'm more concerned about the other direction: can we be sure that a
status value less than 255 is from exit() rather than something that
should be called an exception?

And to get back to the point, surely all this confusion proves the point
about how the error message should NOT try to tell people how to
interpret the number.

regards, tom lane

Takayuki Tsunakawa wrote:

From: "Magnus Hagander" <magnus@hagander.net>

Are you entirely sure that ntstatus.h is where to look? Because per
whatever docs I've found, that contains "device driver errors" and

*not*

exception codes.

Yes, what you are pointing out is correct. winbase.h and winnt.h
should be consulted instead of ntstatus.h. See the the section
"Return Value" in the following page:

http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx

Well, it seems to be in two place. I see at:

http://www.microsoft.com/msj/0197/exception/exception.aspx

The ExceptionCode parameter is the number that the operating system
assigned to the exception. You can see a list of various exception codes
in WINNT.H by searching for #defines that start with "STATUS_". For
example, the code for the all-too-familiar STATUS_ACCESS_VIOLATION is
0xC0000005. A more complete set of exception codes can be found in
NTSTATUS.H from the Windows NT DDK.

And it seems Wine also has it in both places. The nice thing about
ntstatus.h is that it _only_ contains exception values, rather than
winnt.h, which has lots of other stuff too.

Furthermore, the message is meaningless for users because they can do
nothing with the information. So, I think the message should say
something like

child process was terminated by exception %X
This seems to be a bug of PostgreSQL.
Please report this message with the details of the phynomenon to
PostgreSQL developers.

I am hoping some of the hex values will have descriptions that will help
users solve problems in their operating system configuration, rather
than asking us. If they are in a crisis, asking the community might
not be quick enough.

FYI, here is a patch that recommends ntstatus.h:

http://blog.opsan.com/archive/2005/05/05/447.aspx
http://www.osronline.com/article.cfm?article=207

This says you can get text for exceptions, but it didn't work for me,
but I didn't try loading ntdll.dll:

http://support.microsoft.com/kb/259693

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, Jan 23, 2007 at 10:26:29AM -0500, Bruce Momjian wrote:

Magnus Hagander wrote:

On Tue, Jan 23, 2007 at 10:11:58AM -0500, Bruce Momjian wrote:

Magnus Hagander wrote:

I think that's incorrect information to the user :-(
If the child terminates with exit(1), we will then say "child process
was terminated by exception 1. This seems to be a bug", which is clearly
not true.

Unless you know a sure way of determining if the exitcode is a normal
exitcode or an exception code.

Current CVS believes values >= 0x100 are non-exit() terminations.

Why does it do that :-) That's clearly wrong. There are plenty of
exitcodes > 0x100 that aren't exceptions.

Please read include/port/win32.h comment section on this and then reply.
We only care about non-exit() exits.

Right. I did. and exit() can return a lot of error codes > 0x100. For example,
a simple:
int main(int argc, char *argv) {
exit(12345);
}

Yes, I know it works, but it can return 0xc0000005 too. I think we have
to be reasonable and say >= 0x100 is probably the OS.

Depends on what you mean with OS.
There are a *lot* of tools that will return exitcodes >0x100 that are
part of the OS. As a relevant example, Windows installer will return
exitcode 3010 means "needs to reboot but didn't reboot". MSI is a part
of the OS, but it's not kernel... Same thing for things like the service
control manager (trying to operate on a service that has been removed
gives you error 1060).

would break that assumption. (And yes, it works)
exit() takes a 32-bit signed integer, and that's what comes out to the
calling program (verified both with console and standalone program)

The MSDN link referes to the DDK which has to do with driver
development, not userspace. AFAIK, that list is not relevant here, and
I've seen no actual reference so far that it should be used to look up
exit codes.

Now, if we're only caring about exit() from *postgresqls own processes*,
that might hold true. In which case I withdraw that objection as long as
the comment i updated to reflect this ;-) But if we're talking about
exit() in general of any process, then it's simply wrong.

Right, that code is only used by the backend and tools.

We should be very clear about that in our comment then, and the current
comment is not. And the part referring to the DDK should just be
removed, because it's simply incorrect.

For example, don't we call cmd for PITR scripts? If we're using any of
these macros on the return value from there we are *NOT* certain of what
it will be, and then need to document that as a requirement on those
scripts.

//Magnus

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Magnus Hagander wrote:

Now, if we're only caring about exit() from *postgresqls own processes*,
that might hold true. In which case I withdraw that objection as long as
the comment i updated to reflect this ;-) But if we're talking about
exit() in general of any process, then it's simply wrong.

Right, that code is only used by the backend and tools.

We can reasonably assume that no Postgres code will exit() with a value
bigger than 255, because to do so would be unportable.

I'm more concerned about the other direction: can we be sure that a
status value less than 255 is from exit() rather than something that
should be called an exception?

Here are the values listed in ntstatus.h < 0x100:

36 #define STATUS_WAIT_0 ((NTSTATUS) 0x00000000)
37 #define STATUS_WAIT_1 ((NTSTATUS) 0x00000001)
38 #define STATUS_WAIT_2 ((NTSTATUS) 0x00000002)
39 #define STATUS_WAIT_3 ((NTSTATUS) 0x00000003)
40 #define STATUS_WAIT_63 ((NTSTATUS) 0x0000003f)
41 #define STATUS_ABANDONED ((NTSTATUS) 0x00000080)
42 #define STATUS_ABANDONED_WAIT_0 ((NTSTATUS) 0x00000080)
43 #define STATUS_ABANDONED_WAIT_63 ((NTSTATUS) 0x000000BF)
44 #define STATUS_USER_APC ((NTSTATUS) 0x000000C0)

And to get back to the point, surely all this confusion proves the point
about how the error message should NOT try to tell people how to
interpret the number.

This all started because we as a community couldn't interpret the
number. I don't see how pushing the interpetation to users helps us.
We need to nail this down.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, Jan 23, 2007 at 10:32:58AM -0500, Bruce Momjian wrote:

Takayuki Tsunakawa wrote:

From: "Magnus Hagander" <magnus@hagander.net>

Are you entirely sure that ntstatus.h is where to look? Because per
whatever docs I've found, that contains "device driver errors" and

*not*

exception codes.

Yes, what you are pointing out is correct. winbase.h and winnt.h
should be consulted instead of ntstatus.h. See the the section
"Return Value" in the following page:

http://msdn2.microsoft.com/ru-ru/library/ms679356.aspx

Well, it seems to be in two place. I see at:

http://www.microsoft.com/msj/0197/exception/exception.aspx

The ExceptionCode parameter is the number that the operating system
assigned to the exception. You can see a list of various exception codes
in WINNT.H by searching for #defines that start with "STATUS_". For
example, the code for the all-too-familiar STATUS_ACCESS_VIOLATION is
0xC0000005. A more complete set of exception codes can be found in
NTSTATUS.H from the Windows NT DDK.

Actually, that's the first reference so far to say that a kernel level
error code is the same as a userspace exception code. If it is, then
it's safe to use as such. MSJ is generall a very good reference for
these things, even though it's nto an actual documentation.

Furthermore, the message is meaningless for users because they can do
nothing with the information. So, I think the message should say
something like

child process was terminated by exception %X
This seems to be a bug of PostgreSQL.
Please report this message with the details of the phynomenon to
PostgreSQL developers.

I am hoping some of the hex values will have descriptions that will help
users solve problems in their operating system configuration, rather
than asking us. If they are in a crisis, asking the community might
not be quick enough.

FYI, here is a patch that recommends ntstatus.h:

http://blog.opsan.com/archive/2005/05/05/447.aspx
http://www.osronline.com/article.cfm?article=207

This second one is referring to DDK again. The first one doesn't refer
to what it's looking up at all :-(

This says you can get text for exceptions, but it didn't work for me,
but I didn't try loading ntdll.dll:

http://support.microsoft.com/kb/259693

Loading ntdll.dll lets you see Kernel mode API errors. If these are
indeed the same as userspace exceptions, then you can load ntdll to get
those. If you don't load ntdll, you can only look at "normal errors".

//Magnus

Magnus Hagander wrote:

On Tue, Jan 23, 2007 at 10:26:29AM -0500, Bruce Momjian wrote:

Magnus Hagander wrote:

On Tue, Jan 23, 2007 at 10:11:58AM -0500, Bruce Momjian wrote:

Magnus Hagander wrote:

I think that's incorrect information to the user :-(
If the child terminates with exit(1), we will then say "child process
was terminated by exception 1. This seems to be a bug", which is clearly
not true.

Unless you know a sure way of determining if the exitcode is a normal
exitcode or an exception code.

Current CVS believes values >= 0x100 are non-exit() terminations.

Why does it do that :-) That's clearly wrong. There are plenty of
exitcodes > 0x100 that aren't exceptions.

Please read include/port/win32.h comment section on this and then reply.
We only care about non-exit() exits.

Right. I did. and exit() can return a lot of error codes > 0x100. For example,
a simple:
int main(int argc, char *argv) {
exit(12345);
}

Yes, I know it works, but it can return 0xc0000005 too. I think we have
to be reasonable and say >= 0x100 is probably the OS.

Depends on what you mean with OS.
There are a *lot* of tools that will return exitcodes >0x100 that are
part of the OS. As a relevant example, Windows installer will return
exitcode 3010 means "needs to reboot but didn't reboot". MSI is a part
of the OS, but it's not kernel... Same thing for things like the service
control manager (trying to operate on a service that has been removed
gives you error 1060).

Is there a portable way to get the _exception_ value from system(),
rather than the error code? We could go with just > 0xC0000000 values
as exceptions. (This is clearly showing the mess that is the WIN32
API.)

would break that assumption. (And yes, it works)
exit() takes a 32-bit signed integer, and that's what comes out to the
calling program (verified both with console and standalone program)

The MSDN link referes to the DDK which has to do with driver
development, not userspace. AFAIK, that list is not relevant here, and
I've seen no actual reference so far that it should be used to look up
exit codes.

Now, if we're only caring about exit() from *postgresqls own processes*,
that might hold true. In which case I withdraw that objection as long as
the comment i updated to reflect this ;-) But if we're talking about
exit() in general of any process, then it's simply wrong.

Right, that code is only used by the backend and tools.

We should be very clear about that in our comment then, and the current
comment is not. And the part referring to the DDK should just be
removed, because it's simply incorrect.

For example, don't we call cmd for PITR scripts? If we're using any of
these macros on the return value from there we are *NOT* certain of what
it will be, and then need to document that as a requirement on those
scripts.

The major place we use it is for backend termination checking, and we
know the return values there. The other place is for the return value
of pipe().

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Magnus Hagander wrote:

This says you can get text for exceptions, but it didn't work for me,
but I didn't try loading ntdll.dll:

http://support.microsoft.com/kb/259693

Loading ntdll.dll lets you see Kernel mode API errors. If these are
indeed the same as userspace exceptions, then you can load ntdll to get
those. If you don't load ntdll, you can only look at "normal errors".

OK, interesting. Let me test in that direction.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Tue, Jan 23, 2007 at 10:40:40AM -0500, Bruce Momjian wrote:

Depends on what you mean with OS.
There are a *lot* of tools that will return exitcodes >0x100 that are
part of the OS. As a relevant example, Windows installer will return
exitcode 3010 means "needs to reboot but didn't reboot". MSI is a part
of the OS, but it's not kernel... Same thing for things like the service
control manager (trying to operate on a service that has been removed
gives you error 1060).

Is there a portable way to get the _exception_ value from system(),
rather than the error code? We could go with just > 0xC0000000 values
as exceptions. (This is clearly showing the mess that is the WIN32
API.)

AFAIK, the way to do that is to use SEH. But this is not supported by
MingW.

would break that assumption. (And yes, it works)
exit() takes a 32-bit signed integer, and that's what comes out to the
calling program (verified both with console and standalone program)

The MSDN link referes to the DDK which has to do with driver
development, not userspace. AFAIK, that list is not relevant here, and
I've seen no actual reference so far that it should be used to look up
exit codes.

Now, if we're only caring about exit() from *postgresqls own processes*,
that might hold true. In which case I withdraw that objection as long as
the comment i updated to reflect this ;-) But if we're talking about
exit() in general of any process, then it's simply wrong.

Right, that code is only used by the backend and tools.

We should be very clear about that in our comment then, and the current
comment is not. And the part referring to the DDK should just be
removed, because it's simply incorrect.

For example, don't we call cmd for PITR scripts? If we're using any of
these macros on the return value from there we are *NOT* certain of what
it will be, and then need to document that as a requirement on those
scripts.

The major place we use it is for backend termination checking, and we
know the return values there. The other place is for the return value
of pipe().

I assume you mean popen()/pclose()? Because pipe() is implemented using
sockets in our win32 ports layer.

//Magnus

Magnus Hagander wrote:

The major place we use it is for backend termination checking, and we
know the return values there. The other place is for the return value
of pipe().

I assume you mean popen()/pclose()? Because pipe() is implemented using
sockets in our win32 ports layer.

Yes, popen/pclose.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

I worked with Magnus and it seems pulling message text from ntdll.dll
doesn't work for all cases, so we are left just suggesting
/include/ntstatus.h, which is what we have now. Magnus concurs.

---------------------------------------------------------------------------

Magnus Hagander wrote:

On Tue, Jan 23, 2007 at 10:40:40AM -0500, Bruce Momjian wrote:

Depends on what you mean with OS.
There are a *lot* of tools that will return exitcodes >0x100 that are
part of the OS. As a relevant example, Windows installer will return
exitcode 3010 means "needs to reboot but didn't reboot". MSI is a part
of the OS, but it's not kernel... Same thing for things like the service
control manager (trying to operate on a service that has been removed
gives you error 1060).

Is there a portable way to get the _exception_ value from system(),
rather than the error code? We could go with just > 0xC0000000 values
as exceptions. (This is clearly showing the mess that is the WIN32
API.)

AFAIK, the way to do that is to use SEH. But this is not supported by
MingW.

would break that assumption. (And yes, it works)
exit() takes a 32-bit signed integer, and that's what comes out to the
calling program (verified both with console and standalone program)

The MSDN link referes to the DDK which has to do with driver
development, not userspace. AFAIK, that list is not relevant here, and
I've seen no actual reference so far that it should be used to look up
exit codes.

Now, if we're only caring about exit() from *postgresqls own processes*,
that might hold true. In which case I withdraw that objection as long as
the comment i updated to reflect this ;-) But if we're talking about
exit() in general of any process, then it's simply wrong.

Right, that code is only used by the backend and tools.

We should be very clear about that in our comment then, and the current
comment is not. And the part referring to the DDK should just be
removed, because it's simply incorrect.

For example, don't we call cmd for PITR scripts? If we're using any of
these macros on the return value from there we are *NOT* certain of what
it will be, and then need to document that as a requirement on those
scripts.

The major place we use it is for backend termination checking, and we
know the return values there. The other place is for the return value
of pipe().

I assume you mean popen()/pclose()? Because pipe() is implemented using
sockets in our win32 ports layer.

//Magnus

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Win32 exception codes start with a two-bit severity indication.
00 means "success", so nothing is wrong.
01 is an "informational" messages.
10 is a "warning" message.
11 is an "error".

That's why the common exception codes you see start with hex C0, as they
are "errors".

The rest of the top 16 bits are the "facility" that caused the error.
Often not filled in.

To Convert an NT exception code (ntstatus) to a Win32 error code, you
call this routine:

ULONG RtlNtStatusToDosError(
NTSTATUS Status
);

Then you can pass it to FormatMessage and it will work.

-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: Tuesday, January 23, 2007 7:35 AM
To: Tom Lane
Cc: Magnus Hagander; Takayuki Tsunakawa; PostgreSQL-patches; Alvaro
Herrera; ITAGAKI Takahiro
Subject: Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Magnus Hagander wrote:

Now, if we're only caring about exit() from *postgresqls own

processes*,

that might hold true. In which case I withdraw that objection as

long as

the comment i updated to reflect this ;-) But if we're talking

about

exit() in general of any process, then it's simply wrong.

Right, that code is only used by the backend and tools.

We can reasonably assume that no Postgres code will exit() with a

value

Chuck McDevitt wrote:

Win32 exception codes start with a two-bit severity indication.
00 means "success", so nothing is wrong.
01 is an "informational" messages.
10 is a "warning" message.
11 is an "error".

That's why the common exception codes you see start with hex C0, as they
are "errors".

The rest of the top 16 bits are the "facility" that caused the error.
Often not filled in.

Almost, AAUI. The next significant bit after the severity bits is a
custom flag - 0 indicates it is a MS exception, 1 that it's from a third
party. The remaining upper 13 bits are the facility.

cheers

andrew

Chuck McDevitt wrote:

Win32 exception codes start with a two-bit severity indication.
00 means "success", so nothing is wrong.
01 is an "informational" messages.
10 is a "warning" message.
11 is an "error".

That's why the common exception codes you see start with hex C0, as they
are "errors".

The rest of the top 16 bits are the "facility" that caused the error.
Often not filled in.

To Convert an NT exception code (ntstatus) to a Win32 error code, you
call this routine:

ULONG RtlNtStatusToDosError(
NTSTATUS Status
);

Then you can pass it to FormatMessage and it will work.

I looked on MinGW and it seems it doesn't support
RtlNtStatusToDosError(), so I just added a comment that some day we
might want to use it:

* Some day we might want to print descriptions for the most common
* exceptions, rather than printing an include file name. We could use
* RtlNtStatusToDosError() and pass to FormatMessage(), which can print
* the text of error values, but MinGW does not support
* RtlNtStatusToDosError().

---------------------------------------------------------------------------

-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: Tuesday, January 23, 2007 7:35 AM
To: Tom Lane
Cc: Magnus Hagander; Takayuki Tsunakawa; PostgreSQL-patches; Alvaro
Herrera; ITAGAKI Takahiro
Subject: Re: [pgsql-patches] [HACKERS] Win32 WEXITSTATUS too

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Magnus Hagander wrote:

Now, if we're only caring about exit() from *postgresqls own

processes*,

that might hold true. In which case I withdraw that objection as

long as

the comment i updated to reflect this ;-) But if we're talking

about

exit() in general of any process, then it's simply wrong.

Right, that code is only used by the backend and tools.

We can reasonably assume that no Postgres code will exit() with a

value

bigger than 255, because to do so would be unportable.

I'm more concerned about the other direction: can we be sure that a
status value less than 255 is from exit() rather than something that
should be called an exception?

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +