Re: Win32 WEXITSTATUS too simplistic

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Win32 WEXITSTATUS too simplistic
Date: 2006-12-27 01:31:15
Message-ID: 20061227100932.6100.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Glen Parker 2006-12-27 01:51:34 Re: Patch(es) to expose n_live_tuples and
Previous Message Joshua D. Drake 2006-12-27 00:50:31 Re: effective_cache_size vs units

Browse pgsql-patches by date

  From Date Subject
Next Message Glen Parker 2006-12-27 01:51:34 Re: Patch(es) to expose n_live_tuples and
Previous Message Alvaro Herrera 2006-12-27 00:38:45 Re: Patch(es) to expose n_live_tuples and