Обсуждение: Win32 WEXITSTATUS too simplistic
win32.h says /** Signal stuff* WIN32 doesn't have wait(), so the return value for children* is simply the return value specifiedby 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 herehttp://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? regards, tom lane
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