Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Win32 WEXITSTATUS too simplistic

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Win32 WEXITSTATUS too simplistic
Date: 2007-01-22 04:52:55
Message-ID: 200701220452.l0M4qtf04022@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
I did some research on this, and found a nice Win32 list of STATUS_
error values.  Looking at the list, I think the non-exit() return values
are much larger than just the second high bit.

I am proposing the attached patch, which basically has all system()
return values < 0x100 as exit() calls, and everything above that as a
signal exits.  I also think it is too risky to backpatch to 8.2.X.

Also, should we print Win32 WTERMSIG() values as hex because they are so
large?  I have added that to the patch.

---------------------------------------------------------------------------

ITAGAKI Takahiro wrote:
> 
> 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
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq

-- 
  Bruce Momjian   bruce(at)momjian(dot)us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Attachment: /pgpatches/win32
Description: text/x-diff (4.1 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-01-22 07:07:00
Subject: Re: DROP FUNCTION failure: cache lookup failed for relation X
Previous:From: Michael FuhrDate: 2007-01-22 04:45:19
Subject: DROP FUNCTION failure: cache lookup failed for relation X

pgsql-patches by date

Next:From: Tom LaneDate: 2007-01-22 07:07:00
Subject: Re: DROP FUNCTION failure: cache lookup failed for relation X
Previous:From: Michael FuhrDate: 2007-01-22 04:45:19
Subject: DROP FUNCTION failure: cache lookup failed for relation X

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group