| 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: | Whole Thread | Raw Message | 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) |