Обсуждение: Need help with TRAP: FailedAssertion("!(context != CurrentMemoryContext)"

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)

I have run it in single user mode with valgrind on linux and it is clean 
from memory overwrites or leaks. I fails under mingw 32 bit and mingw 64 
bit builds. I have other code that works fine so I don't think it is a 
build environment issue.

I have also run tests on the library using a test harness (ie: outside 
of postgresql) and it runs clean on windows and linux.

The code runs and generates the correct results, and this crash is when 
I call SPI_finish().

So I would appreciate any ideas on how I can trace done the issue and 
fix it.

Thanks,  -Steve


The code and my mingw build is below, the paths would need to change for 
another environment. The source file in questions is 
address_standardizer.c if you want to look at it. If you want to run it 
let me know and I can provide details.

#!/bin/sh
wget -O pagc-postgresql.tgz 
'http://pagc.svn.sourceforge.net/viewvc/pagc/branches/sew-refactor/postgresql/?view=tar'
rm -rf postgresql
tar xzf pagc-postgresql.tgz
cd postgresql

export 

PATH='/c/ming32/projects/gettext/rel-gettext-0.18.1/bin:/c/ming32/projects/xsltproc:/c/ming32/projects/gtk/bin:/c/ming32/projects/rel-libiconv-1.13.1w32/include:.:/bin:/include:/mingw/bin:/mingw/include:/c/Windows/system32:/c/Windows:/usr/local/bin:/c/ming32/Silksvn/bin::/c/ming32/projects/pgx32/pg92w32/bin:/c/ming32/projects/pgx32/pg92w32/lib'

make SHLIB_LINK="-L/c/ming32/msys/local/lib -Wl,--enable-stdcall-fixup 
-lpostgres -lpgport -lwsock32 -lm  -lws2_32 -lshfolder -lpcre" 
CPPFLAGS=-I/usr/local/include && make install

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

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
stuffin 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

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
>
>

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