[Bug fix] postmaster always crashes on a debug version of Windows - Mailing list pgsql-bugs
From | MauMau |
---|---|
Subject | [Bug fix] postmaster always crashes on a debug version of Windows |
Date | |
Msg-id | 9B64D90FC69E4432BBFA5D72D1844F64@maumau Whole thread Raw |
List | pgsql-bugs |
Hello Let me also post this here at pgsql-bugs just in case, though I post it pgsql-hackers on Feb 16. ---------- Hello I encountered a bug which always causes PostgreSQL to crash on Windows. Attached is a patch that fixes it. Please review it and include it in the upcoming minor releases of supported versions. The following is a bug report. Your name :MauMau Your email address :maumau307@gmail.com System Configuration: --------------------- Architecture (example: Intel Pentium) : Intel Xeon Operating System (example: Linux 2.4.18) : I found the bug on Windows 2008 R2 Enterprise x64 Edition, but it should apply to all versions of Windows. PostgreSQL version (example: PostgreSQL 9.1.1): PostgreSQL 8.3.12 However, the problem should happen on all versions of PostgreSQL. Compiler used (example: gcc 3.3.5) : Visual Studio 2005 Professional Edition Please enter a FULL description of your problem: ------------------------------------------------ On a debug version of Windows, PostgreSQL server fails to start. When I run "pg_ctl start" on the command prompt, pg_ctl displays "server starting", but the PostgreSQL server does not start. No message is left which tells the cause. pg_ctl does not show any error messages on the command prompt. Even when I include 'eventlog' in log_destination parameter, no error message is recorded in the application log nor the system log of Windows event log. This problem does not occur on a release version of Windows. Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: ---------------------------------------------------------------------- On a debug version of Windows, do the following: 1. Run initdb. initdb's option is not relevant. 2. Set logging_collector to on in postgresql.conf. 3. Run "pg_ctl start" on the command prompt. The problem does not happen when logging_collector is off. If you know how this problem might be fixed, list the solution below: --------------------------------------------------------------------- [Cause] postmaster crashes in the following CloseHandle() call, which is at line 591 in src/backend/postmaster/syslogger.c (in case of PostgreSQL 9.1.) /* Now we are done with the write end of the pipe. */ CloseHandle(syslogPipe[1]); The CloseHandle() crashes because it receives an already closed handle. According the following MSDN article, CloseHandle() causes a crash under a debugger. Though I'm not exactly sure, I guess running on the debug version of Windows is equivalent to running under a debugger. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724211(v=vs.85).aspx [Excerpt] If the application is running under a debugger, the function will throw an exception if it receives either a handle value that is not valid or a pseudo-handle value. This can happen if you close a handle twice, or if you call CloseHandle on a handle returned by the FindFirstFile function instead of calling the FindClose function. Then, where is the handle closed? It was closed in close() at three lines above. The pipe handle is associated with a file descriptor by _open_osfhandle(). Calling close() for the file descriptor also closes the underlying handle. See the MSDN article: http://msdn.microsoft.com/en-us/library/bdts1c9x(v=vs.80).aspx [Excerpt] To close a file opened with _open_osfhandle, call _close. The underlying handle is also closed by a call to _close, so it is not necessary to call the Win32 function CloseHandle on the original handle. [Fix] Remove the unnecessary CloseHandle() call. I sought similar extra closing by checking places where _open_osfhandle() or _get_osfhandle() is used, but there was nothing elsewhere. I attached a patch against the master HEAD. Is it OK with a patch that has CR-LF line endings? Regards
Attachment
pgsql-bugs by date: