Need help with TRAP: FailedAssertion("!(context != CurrentMemoryContext)"

On 2013-04-20 16:32:36 -0400, Stephen Woodbridge wrote:

Hi all,

I have been writing pg extensions for a while but I just ran into a problem
that has me stumped.

I have code for a SRF and it works fine on pg 9.2.2 on linux, but fails with
am error in the logfile.

TRAP: FailedAssertion("!(context != CurrentMemoryContext)", File: "mcxt.c",
Line: 172)

This means that the current memory context is being deleted. Are you
doing that or did you maybe MemoryContextSwitchTo to some context but
not back?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 4/20/2013 5:00 PM, Andres Freund wrote:

On 2013-04-20 16:32:36 -0400, Stephen Woodbridge wrote:

Hi all,

I have been writing pg extensions for a while but I just ran into a problem
that has me stumped.

I have code for a SRF and it works fine on pg 9.2.2 on linux, but fails with
am error in the logfile.

TRAP: FailedAssertion("!(context != CurrentMemoryContext)", File: "mcxt.c",
Line: 172)

This means that the current memory context is being deleted. Are you
doing that or did you maybe MemoryContextSwitchTo to some context but
not back?

Andres,

Thank you for your reply. The frustrating thing about this is the same
source works fine in Linux. So here is the pseudo code of my source
removing non pgsql stuff and not expected to be runnable:

PG_FUNCTION_INFO_V1(myfunc);
Datum myfunc(PG_FUNCTION_ARGS)
{
if (SRF_IS_FIRSTCALL()) {
funcctx = SRF_FIRSTCALL_INIT();
oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
SPIcode = SPI_connect();

// execute some SPI queries and load some structures
// execute a query and save the tuptable and
// other stuff in funcctx->user_fctx

MemoryContextSwitchTo(oldcontext);
}

funcctx = SRF_PERCALL_SETUP();

if (call_cntr < max_calls) {

// process a row in my saved tuptable

SRF_RETURN_NEXT(funcctx, result)
}
else { // we are all done cleanup
// free stuff from my library
SPI_freetuptable(my_tuptable);
SPIcode = SPI_finish(); // <<<<< CRASHES HERE >>>>>
SRF_RETURN_DONE(funcctx);
}
}

So, like I said, it runs on Linux not in MinGW on windows. Anyway, did I
mess up the memory context switching? Is there a way I can force the
context to the appropriate place.

Thanks,
-Steve

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

OK, it looks like there is a bug related to MinGW builds. If I remove
both --enable-cassert --enable-debug from my configure then I get a
build that works. Removing just --enable-cassert did not solve the
problem. I did not try just removing --enable-debug only.

Someone might want to look into this.

Thanks,
-Steve

On 4/20/2013 8:21 PM, Stephen Woodbridge wrote:

On 4/20/2013 5:00 PM, Andres Freund wrote:

On 2013-04-20 16:32:36 -0400, Stephen Woodbridge wrote:

Hi all,

I have been writing pg extensions for a while but I just ran into a
problem
that has me stumped.

I have code for a SRF and it works fine on pg 9.2.2 on linux, but
fails with
am error in the logfile.

TRAP: FailedAssertion("!(context != CurrentMemoryContext)", File:
"mcxt.c",
Line: 172)

This means that the current memory context is being deleted. Are you
doing that or did you maybe MemoryContextSwitchTo to some context but
not back?

Andres,

Thank you for your reply. The frustrating thing about this is the same
source works fine in Linux. So here is the pseudo code of my source
removing non pgsql stuff and not expected to be runnable:

PG_FUNCTION_INFO_V1(myfunc);
Datum myfunc(PG_FUNCTION_ARGS)
{
if (SRF_IS_FIRSTCALL()) {
funcctx = SRF_FIRSTCALL_INIT();
oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
SPIcode = SPI_connect();

// execute some SPI queries and load some structures
// execute a query and save the tuptable and
// other stuff in funcctx->user_fctx

MemoryContextSwitchTo(oldcontext);
}

funcctx = SRF_PERCALL_SETUP();

if (call_cntr < max_calls) {

// process a row in my saved tuptable

SRF_RETURN_NEXT(funcctx, result)
}
else { // we are all done cleanup
// free stuff from my library
SPI_freetuptable(my_tuptable);
SPIcode = SPI_finish(); // <<<<< CRASHES HERE >>>>>
SRF_RETURN_DONE(funcctx);
}
}

So, like I said, it runs on Linux not in MinGW on windows. Anyway, did I
mess up the memory context switching? Is there a way I can force the
context to the appropriate place.

Thanks,
-Steve

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Stephen Woodbridge <woodbri@swoodbridge.com> writes:

Thank you for your reply. The frustrating thing about this is the same
source works fine in Linux. So here is the pseudo code of my source
removing non pgsql stuff and not expected to be runnable:

You can't hold a SPI context open across multiple calls of an SRF.
Even if it somehow failed to malfunction in isolation, this would
certainly not work in a query where some other called function was
also using SPI.

Possibly the reason the code accidentally fails to malfunction on Linux
is you're not using an --enable-cassert build there? That would wipe
freed memory and thus help to reveal errors of this sort consistently,
whereas otherwise the failures would be context-dependent.

[ later ]

Someone might want to look into this.

Even if there were good reason to think this was a system bug and not
yours, there's little anyone else can do when you've not provided a
complete, concrete test case.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers