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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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 Content-Type Size
/pgpatches/win32 text/x-diff 4.1 KB

In response to

Responses

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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