Re: postgres.exe has encountered a problem on windows

Started by Rushabh Lathiaalmost 15 years ago4 messages

rushabh.lathia@gmail.com

almost 15 years ago

On Fri, Apr 1, 2011 at 6:51 PM, Magnus Hagander <magnus@hagander.net> wrote:

On Fri, Apr 1, 2011 at 15:14, Rushabh Lathia <rushabh.lathia@gmail.com>
wrote:

Problem:
========

On windows when we run postgres.exe without any command line args, its
getting crash or its showing error into Application logs of Event Viewer.

Analysis:
==========

For any stderr we call the write_stderr() and write_stderr() calls the
write_console() for stderr. Now here write_console() using the palloc()
internally, which require the CurrentMemoryContext.

At the startup CurrentMemoryContext will be NULL, so palloc again calling
write_stderr(). So recursion has been started and its ending up with
exception.

Call stack for palloc() is:

main() -> check_root() -> write_stderr() -> write_console() ->
pgwin32_toUTF16() -> palloc()

Fix:
=====

Earlier we used to call vfprintf() for windows stderr, which is now
replaced with write_console().
So to avoid the exception now, I added condition for CurrentMemoryContext
into write_stderr().

PFA patch to fix the same.

What about the cases where we directly call write_console()? Do we
know we are good there, or should the check perhaps be made inside
write_console() instead of in the caller?

Hmm, yes. It make more sense to add check for CurrentMemoryContext in
write_console().

PFA patch for the same.

Regards,
Rushabh Lathia
EnterpriseDB, The Enterprise PostgreSQL company.

Rushabh Lathia

rushabh.lathia@gmail.com

almost 15 years ago

In reply to: Rushabh Lathia (#1)

1 attachment(s)

On Fri, Apr 1, 2011 at 8:23 PM, Rushabh Lathia <rushabh.lathia@gmail.com>wrote:

On Fri, Apr 1, 2011 at 6:51 PM, Magnus Hagander <magnus@hagander.net>wrote:

On Fri, Apr 1, 2011 at 15:14, Rushabh Lathia <rushabh.lathia@gmail.com>
wrote:

Problem:
========

On windows when we run postgres.exe without any command line args, its
getting crash or its showing error into Application logs of Event

Viewer.

Analysis:
==========

For any stderr we call the write_stderr() and write_stderr() calls the
write_console() for stderr. Now here write_console() using the palloc()
internally, which require the CurrentMemoryContext.

At the startup CurrentMemoryContext will be NULL, so palloc again

calling

write_stderr(). So recursion has been started and its ending up with
exception.

Call stack for palloc() is:

main() -> check_root() -> write_stderr() -> write_console() ->
pgwin32_toUTF16() -> palloc()

Fix:
=====

Earlier we used to call vfprintf() for windows stderr, which is now
replaced with write_console().
So to avoid the exception now, I added condition for

CurrentMemoryContext

into write_stderr().

PFA patch to fix the same.

What about the cases where we directly call write_console()? Do we
know we are good there, or should the check perhaps be made inside
write_console() instead of in the caller?

Hmm, yes. It make more sense to add check for CurrentMemoryContext in
write_console().

PFA patch for the same.

Oops missed the attachment.

Here it is ..

Show quoted text

Regards,
Rushabh Lathia
EnterpriseDB, The Enterprise PostgreSQL company.

Attachments:

win_crash_fix_v2.patchtext/x-diff; charset=US-ASCII; name=win_crash_fix_v2.patchDownload

Index: src/backend/utils/error/elog.c
===================================================================
RCS file: /repositories/postgreshome/cvs/pgsql/src/backend/utils/error/elog.c,v
retrieving revision 1.226
diff -c -p -r1.226 elog.c
*** src/backend/utils/error/elog.c	19 Aug 2010 22:55:01 -0000	1.226
--- src/backend/utils/error/elog.c	1 Apr 2011 15:47:01 -0000
*************** write_console(const char *line, int len)
*** 1661,1667 ****
  	 */
  	if (GetDatabaseEncoding() != GetPlatformEncoding() &&
  		!in_error_recursion_trouble() &&
! 		!redirection_done)
  	{
  		WCHAR	   *utf16;
  		int			utf16len;
--- 1661,1668 ----
  	 */
  	if (GetDatabaseEncoding() != GetPlatformEncoding() &&
  		!in_error_recursion_trouble() &&
! 		!redirection_done &&
! 		CurrentMemoryContext)
  	{
  		WCHAR	   *utf16;
  		int			utf16len;

Magnus Hagander

magnus@hagander.net

almost 15 years ago

In reply to: Rushabh Lathia (#2)

On Fri, Apr 1, 2011 at 16:56, Rushabh Lathia <rushabh.lathia@gmail.com> wrote:

On Fri, Apr 1, 2011 at 8:23 PM, Rushabh Lathia <rushabh.lathia@gmail.com>
wrote:

On Fri, Apr 1, 2011 at 6:51 PM, Magnus Hagander <magnus@hagander.net>
wrote:

On Fri, Apr 1, 2011 at 15:14, Rushabh Lathia <rushabh.lathia@gmail.com>
wrote:

Problem:
========

On windows when we run postgres.exe without any command line args, its
getting crash or its showing error into Application logs of Event
Viewer.

Analysis:
==========

For any stderr we call the write_stderr() and write_stderr() calls the
write_console() for stderr. Now here write_console() using the palloc()
internally, which require the CurrentMemoryContext.

At the startup CurrentMemoryContext will be NULL, so palloc again
calling
write_stderr(). So recursion has been started and its ending up with
exception.

Call stack for palloc() is:

main() -> check_root() -> write_stderr() -> write_console() ->
pgwin32_toUTF16() -> palloc()

Fix:
=====

Earlier we used to call vfprintf() for windows stderr, which is now
replaced with write_console().
So to avoid the exception now, I added condition for
CurrentMemoryContext
into write_stderr().

PFA patch to fix the same.

What about the cases where we directly call write_console()? Do we
know we are good there, or should the check perhaps be made inside
write_console() instead of in the caller?

Hmm, yes. It make more sense to add check for CurrentMemoryContext in
write_console().

PFA patch for the same.

Oops missed the attachment.

Here it is ..

Thanks, applied with the addition of a comment.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Rushabh Lathia

rushabh.lathia@gmail.com

almost 15 years ago

In reply to: Magnus Hagander (#3)

On Fri, Apr 1, 2011 at 11:31 PM, Magnus Hagander <magnus@hagander.net>wrote:

On Fri, Apr 1, 2011 at 16:56, Rushabh Lathia <rushabh.lathia@gmail.com>
wrote:

On Fri, Apr 1, 2011 at 8:23 PM, Rushabh Lathia <rushabh.lathia@gmail.com

wrote:

On Fri, Apr 1, 2011 at 6:51 PM, Magnus Hagander <magnus@hagander.net>
wrote:

On Fri, Apr 1, 2011 at 15:14, Rushabh Lathia <rushabh.lathia@gmail.com

wrote:

Problem:
========

On windows when we run postgres.exe without any command line args,

its

getting crash or its showing error into Application logs of Event
Viewer.

Analysis:
==========

For any stderr we call the write_stderr() and write_stderr() calls

the

write_console() for stderr. Now here write_console() using the

palloc()

internally, which require the CurrentMemoryContext.

At the startup CurrentMemoryContext will be NULL, so palloc again
calling
write_stderr(). So recursion has been started and its ending up with
exception.

Call stack for palloc() is:

main() -> check_root() -> write_stderr() -> write_console() ->
pgwin32_toUTF16() -> palloc()

Fix:
=====

Earlier we used to call vfprintf() for windows stderr, which is now
replaced with write_console().
So to avoid the exception now, I added condition for
CurrentMemoryContext
into write_stderr().

PFA patch to fix the same.

What about the cases where we directly call write_console()? Do we
know we are good there, or should the check perhaps be made inside
write_console() instead of in the caller?

Hmm, yes. It make more sense to add check for CurrentMemoryContext in
write_console().

PFA patch for the same.

Oops missed the attachment.

Here it is ..

Thanks, applied with the addition of a comment.

Thanks Magnus.

regards,
Rushabh Lathia
EnterpriseDB, The Enterprise PostgreSQL company.