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?

regards, tom lane

Search Discussions

  • Andrew Dunstan at Dec 26, 2006 at 7:47 pm

    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
  • Tom Lane at Dec 26, 2006 at 8:01 pm

    "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
  • Andrew Dunstan at Dec 26, 2006 at 10:27 pm

    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
  • ITAGAKI Takahiro at Dec 27, 2006 at 1:31 am

    Tom Lane 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedDec 26, '06 at 3:59p
activeDec 27, '06 at 1:31a
posts5
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase