Intermittent bug

Hi,
I have an intermittent bug in PL/Java that only shows up on Win32. Is
there any way of debugging the postgres.exe process that corresponds to
your connection on a win32 (MinGW) platform?

I have a MinGW environment with gdb but I can't figure out how to make
gdb attach to a running process it seems to happily accept any PID and
claim that it's attached although it isn't.

I have a Visual Studio installed too. It's able to attach but it fails
to see any symbols.

Help greatly appreciated,
Thomas Hallgren

After some pretty tedious assembly debugging I've managed to locate the
source of my problem. It is probably similar to a bug involving
MemoryContext life cycle on IMMUTABLE functions that I struggled with
last winter (later fixed by Tom).

This is what happens:

I have an function declared as IMMUTABLE that returns a SETOF tuples. I
palloc some data using the context->multi_call_memory_context during the
SRF_IS_FIRSTCALL phase and I assign that data to the context->user_fctx.

I obtain the context again using SRF_PERCALL_SETUP() and from that my
palloc'ed data. I have verified that I get the exact same pointer. I do,
but the memory that it points to is no longer accessible! I get an
access fault and I can't even display that memory in the debugger. This
tells me that the memory is no longer bound to the process, it must have
been free'd up.

What life span does the context->multi_call_memory_context have in case
of IMMUTABLE functions that returns SETOF?

Regards,
Thomas Hallgren

Thomas Hallgren <thhal(at)mailblocks(dot)com> writes:
> What life span does the context->multi_call_memory_context have in case
> of IMMUTABLE functions that returns SETOF?

It should be long enough. What's your test case exactly?

regards, tom lane

Tom Lane wrote:

>>What life span does the context->multi_call_memory_context have in case
>>of IMMUTABLE functions that returns SETOF?
>>
>>
>It should be long enough. What's your test case exactly?
>
>
It's my PL/Java test framework that fails so it's a bit complex but if
I'm right, any immutable, set-returning function that allocates stuff in
multi_call_memory_context at first call and then reused it, should show
the same problem.

I do have a way of logging MemoryContext termination by replacing the
function pointer used for context delete with an interceptor that does
elog(DEBUG1). I'll see if I can prove that it actually get's deleted
between rows. If it does, perhaps I can find the time to write a sample.

Regards,
Thomas Hallgren

Thomas Hallgren <thhal(at)mailblocks(dot)com> writes:
> It's my PL/Java test framework that fails so it's a bit complex but if
> I'm right, any immutable, set-returning function that allocates stuff in
> multi_call_memory_context at first call and then reused it, should show
> the same problem.

Well, you're not right, because nearly every SRF we have does that.

My thought is that there is something specific to the query you are
using that is a contributing factor...

regards, tom lane

Tom Lane wrote:

>Well, you're not right ...
>
>
That's true. This time it was my own fault altogether I'm afraid.

Regards,
Thomas Hallgren