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

Re: edb-postgres.exe has encountered a problem on windows

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Rushabh Lathia <rushabh(dot)lathia(at)enterprisedb(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Subject: Re: edb-postgres.exe has encountered a problem on windows
Date: 2011-04-01 13:21:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Apr 1, 2011 at 15:14, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> wrote:
> Problem:
> ========
> On windows when we run edb-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?

 Magnus Hagander

In response to

pgsql-hackers by date

Next:From: Shigeru HANADADate: 2011-04-01 13:40:50
Subject: Re: Comments on SQL/Med objects
Previous:From: Rushabh LathiaDate: 2011-04-01 13:14:33
Subject: edb-postgres.exe has encountered a problem on windows

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