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