From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Win32 WEXITSTATUS too simplistic |
Date: | 2006-12-26 15:59:01 |
Message-ID: | 14415.1167148741@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-12-26 16:25:41 | Recent SIGSEGV failures in buildfarm HEAD |
Previous Message | Tom Lane | 2006-12-26 15:47:20 | TupleDescs and refcounts and such, again |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-12-26 16:15:21 | Re: Micro doc patch (plpgsql) |
Previous Message | David Fetter | 2006-12-26 13:04:15 | Re: Micro doc patch (plpgsql) |