Обсуждение: 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@mailblocks.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@mailblocks.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