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

Re: Fwd: Re: BUG #5556: "cannot drop active portal" and "ERRORDATA_STACK_SIZE exceeded" lead to server crash

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Robert Walker <robwalker01(at)speedymail(dot)org>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Fwd: Re: BUG #5556: "cannot drop active portal" and "ERRORDATA_STACK_SIZE exceeded" lead to server crash
Date: 2010-07-13 19:55:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
I found the issue earlier today and posted a small test case to 
reproduce it:

I must've clicked the wrong teply button as you were not CC'd on that. 

The bug should be fixed now.

On 13/07/10 17:57, Robert Walker wrote:
> Attached are text files with the output from the debugging tool. The
> "startup" text file is when the backend was first started, the "crash"
> text file has content that was triggered in the tool when the crash
> occurred, and the "crash_info" text file is additional information I
> requested with "~*k" after the crash.
> As far as a self-contained example goes, I originally tried to make a
> simple test case but it would not crash using the imitation of the
> actual database. Because I wasn't sure what the cause of the crash was,
> it wasn't clear how to make a test case for it. Unfortunately my job
> doesn't let me expose too many details about stuff like this so I
> couldn't post the real details about the database. But I'll try to help
> as much as I can and I hope the stack traces will be helpful.
> On Tue, 13 Jul 2010 11:15 +0800, "Craig Ringer"
> <craig(at)postnewspapers(dot)com(dot)au>  wrote:
>> On 13/07/10 05:00, Robert Walker wrote:
>>> The intent of what I was originally trying to do is to intentionally cause a
>>> unique constraint violation for the sake of testing to ensure that I won't
>>> get duplicate data in the final design. But when the unique violation
>>> occurs, a series of other (possibly related?) errors occur that lead to the
>>> crash.
>>> This application has requested the Runtime to terminate it in an unusual
>>> way.
>>> Please contact the application's support team for more information.
>> It'd be really nice to have a backtrace of that. PostgreSQL binaries for
>> Windows are released with debug information, and if you can reproduce
>> the crash it's not hard to get a stack trace showing a fair bit of
>> information about the state the backend was in when it crashed.
>> See:
>> You'll need Debugging Tools for Windows or even better, the Visual C++
>> Express Edition. Both are free downloads. If you have a paid version of
>> Visual Studio, that's even better.
>> It is very important to set your symbol path up properly, and make sure
>> that the information you collect is useful. See the instructions above.
>> --
>> Craig Ringer
>> Tech-related writing:

   Heikki Linnakangas

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-07-13 22:09:27
Subject: Re: BUG #5559: Full SSL verification fails when hostaddr provided
Previous:From: Robert WalkerDate: 2010-07-13 14:57:52
Subject: Fwd: Re: BUG #5556: "cannot drop active portal" and "ERRORDATA_STACK_SIZE exceeded" lead to server crash

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