Обсуждение: [HACKERS] Error: dsa_area could not attach to a segment that has been freed

Hello everyone, 

Based on the discussion in the below thread, I built a an extension using DSA(postgres-10 beta-3, linux machine).

https://www.postgresql.org/message-id/flat/15cc91e836b.12362f6336537.3402818166899386386%40zohocorp.com#15cc91e836b.12362f6336537.3402818166899386386@zohocorp.com

Use _PG_init and the shmem hook to reserve a little bit of

traditional shared memory and initialise it to zero.  This will be

used just to share the DSA handle, but you can't actually create the

DSA area in postmaster.  In other words, this little bit of shared

memory is for "discovery", since it can be looked up by name from any

backend.

Yes, I have created memory for DSA handle in shared memory, but not the actual DSA area.

In each backend that wants to use your new in-memory index system,

you need to be able to attach or create the DSA area on-demand.

Perhaps you could have a get_my_shared_state() function (insert better

name) that uses a static local variable to hold a pointer to some

state.  If it's NULL, you know you need to create the state.  That

should happen only once in each backend, the first time through the

function.  In that case you need to create or attach to the DSA area

as appropriate, which you should wrap in

LWLockAcquire(AddinShmemInitLock,

LW_EXCLUSIVE)/LWLockRelease(AddinShmemInitLock) to serialise the code

block.  First, look up the bit of traditional shared memory to see if

there is a DSA handle published in it already.  If there is you can

attach.  If there isn't, you are the first so you need to create, and

publish the handle for others to attach to.  Remember whatever state

you need to remember, such as the dsa_area, in static local variables

so that all future calls to get_my_shared_state() in that backend will

be fast.

Yes, the code is present in gstore_shmem.c(pfa) and the first process to use DSA will create the area, and rest all new processes will either attach it or if it is already attached, it will use the DSA area which is already pinned.

==> I have created a bgworker in pg_init and when it starts it will be the first process to access DSA, so it will create DSA area.

==> I have a small UDF function(simple_udf_func) which I call in a new backend(process). So it will attach the DSA area already created.

==> When I make a call to same UDF function again in the same process, since the area is already attached and pinned, I use the same area which I store in a global variable while attaching/creating. Here I get the problem...

Error details: dsa_area could not attach to a segment that has been freed

While examining in detail, I found this data.

I used dsa_dump() for debugging and I found that during my error case, i get this log:

dsa_area handle 1:

  max_total_segment_size: 0

  total_segment_size: 0

  refcnt: 0

  pinned: f

  segment bins:

  segment bin 0 (at least -2147483648 contiguous pages free):

Clearly, the data in my DSA area has been corrupted in latter case, but my bgworker continues to work proper with same dsa_area handle.

At this stage, the dsa_dump() in my bgworker is as below:

dsa_area handle 1814e630:

  max_total_segment_size: 18446744073709551615

  total_segment_size: 1048576

  refcnt: 3

  pinned: t

  segment bins:

    segment bin 8 (at least 128 contiguous pages free):

      segment index 0, usable_pages = 253, contiguous_pages = 220, mapped at 0x7f0abbd58000

As i'm pinning the dsa mapping after attach, it has to stay through out the backend session. But not sure why its freed/corrupted.

Kindly help me in fixing this issue. Attached the copy of my extension, which will reproduce the same issue. 

Regards

G. Sai Ram

On Fri, Sep 15, 2017 at 7:51 PM, Gaddam Sai Ram

<gaddamsairam.n@zohocorp.com> wrote:

> As i'm pinning the dsa mapping after attach, it has to stay through out the

> backend session. But not sure why its freed/corrupted.

>

> Kindly help me in fixing this issue. Attached the copy of my extension,

> which will reproduce the same issue.

Your DSA area is pinned and the mapping is pinned, but there is one

more thing that goes away automatically unless you nail it to the

table: the backend-local dsa_area object which dsa_create() and

dsa_attach() return. That's allocated in the "current memory

context", so if you do it from your procedure simple_udf_func without

making special arrangements it gets automatically freed at end of

transaction. If you're going to cache it for the whole life of the

backend, you'd better make sure it's allocated in memory context that

lives long enough. Where you have dsa_create() and dsa_attach()

calls, try coding like this:

MemoryContext old_context;

old_context = MemoryContextSwitchTo(TopMemoryContext);

area = dsa_create(...);

MemoryContextSwitchTo(old_context);

old_context = MemoryContextSwitchTo(TopMemoryContext);

area = dsa_attach(...);

MemoryContextSwitchTo(old_context);

You'll need to #include "utils/memutils.h".

--

Thomas Munro

http://www.enterprisedb.com

On Wed, Sep 20, 2017 at 6:14 PM, Gaddam Sai Ram

<gaddamsairam.n@zohocorp.com> wrote:

> Thank you very much! That fixed my issue! :)

> I was in an assumption that pinning the area will increase its lifetime but

> yeah after taking memory context into consideration its working fine!

So far the success rate in confusing people who first try to make

long-lived DSA areas and DSM segments is 100%. Basically, this is all

designed to ensure automatic cleanup of resources in short-lived

scopes.

Good luck for your graph project. I think you're going to have to

expend a lot of energy trying to avoid memory leaks if your DSA lives

as long as the database cluster, since error paths won't automatically

free any memory you allocated in it. Right now I don't have any

particularly good ideas for mechanisms to deal with that. PostgreSQL

C has exception-like error handling, but doesn't (and probably can't)

have a language feature like scoped destructors from C++. IMHO

exceptions need either destructors or garbage collection to keep you

sane. There is a kind of garbage collection for palloc'd memory and

also for other resources like file handles, but if you're using a big

long lived DSA area you have nothing like that. You can use

PG_TRY/PG_CATCH very carefully to clean up, or (probably better) you

can try to make sure that all your interaction with shared memory is

no-throw (note that that means using dsa_allocate_extended(x,

DSA_ALLOC_NO_OOM), because dsa_allocate itself can raise errors). The

first thing I'd try would probably be to keep all shmem-allocating

code in as few routines as possible, and use only no-throw operations

in the 'critical' regions of them, and maybe look into some kind of

undo log of things to free or undo in case of error to manage

multi-allocation operations if that turned out to be necessary.

--

Thomas Munro

http://www.enterprisedb.com