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 |
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 |
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 |