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

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@postnewspapers.com.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:
>
>
> http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
>
>
> 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: http://soapyfrogs.blogspot.com/
>
--
Robert Walker (robwalker01@speedymail.org)

[e-mail provided by http://fastmail.fm]

--
http://www.fastmail.fm - A no graphics, no pop-ups email service


--
Robert Walker (robwalker01@speedymail.org)

[e-mail provided by http://fastmail.fm]

--
http://www.fastmail.fm - Same, same, but different...

I found the issue earlier today and posted a small test case to
reproduce it:

http://archives.postgresql.org/pgsql-bugs/2010-07/msg00084.php

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

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@postnewspapers.com.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:
>>
>>
>> http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
>>
>>
>> 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: http://soapyfrogs.blogspot.com/
>>
>>
>>
>>


--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com