Re: [HACKERS] Win32 WEXITSTATUS too simplistic
Tom Lane <[EMAIL PROTECTED]> 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 C005, 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? C005 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 0xCxxx. I think we can use the second high bit to distinguish exit by exception from normal exits. #define WEXITSTATUS(w) ((int) ((w) & 0x4000)) #define WIFEXITED(w)((w) & 0x4000) == 0) #define WIFSIGNALED(w) ((w) & 0x4000) != 0) #define WTERMSIG(w) (w) // or ((w) & 0x3FFF) 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
Re: [HACKERS] Win32 WEXITSTATUS too simplistic
Tom Lane wrote: > "Andrew Dunstan" <[EMAIL PROTECTED]> 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 ---(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
Re: [HACKERS] Win32 WEXITSTATUS too simplistic
"Andrew Dunstan" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 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 C005, 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] 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 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 C005, 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
