Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is This a Memory Leak? #14561

Closed
Zhangwusheng opened this issue Nov 30, 2022 · 11 comments
Closed

Is This a Memory Leak? #14561

Zhangwusheng opened this issue Nov 30, 2022 · 11 comments

Comments

@Zhangwusheng
Copy link

Zhangwusheng commented Nov 30, 2022

Bug Report

In smgr.c:

void
smgr_init_standard(void)
{
	int i;
	for (i = 0; i < NSmgr; i++)
	{
		if (smgrsw[i].smgr_init)
			smgrsw[i].smgr_init();
	}
	mdinit();
}


void
smgrinit(void)
{
	if (smgr_init_hook)
		(*smgr_init_hook)();

	smgr_init_standard();

	/* register the shutdown proc */
	on_proc_exit(smgrshutdown, 0);
}

static const f_smgr smgrsw[] = {
	/* magnetic disk */
	{
		.smgr_init = mdinit,
		.smgr_shutdown = NULL,
		.smgr_close = mdclose,
		.smgr_create = mdcreate,
		.smgr_create_ao = mdcreate_ao,
		.smgr_exists = mdexists,
		.smgr_unlink = mdunlink,
		.smgr_extend = mdextend,
		.smgr_prefetch = mdprefetch,
		.smgr_read = mdread,
		.smgr_write = mdwrite,
		.smgr_nblocks = mdnblocks,
		.smgr_truncate = mdtruncate,
		.smgr_immedsync = mdimmedsync,
		.smgr_pre_ckpt = mdpreckpt,
		.smgr_sync = mdsync,
		.smgr_post_ckpt = mdpostckpt,
	},
};

static const int NSmgr = lengthof(smgrsw);

NSmgr=1 && smgrsw[0].smgr_init = mdinit.

so mdinit will be called twice.

and in mdinit MdCxt will be alloced tiwce?

void
mdinit(void)
{
	MdCxt = AllocSetContextCreate(TopMemoryContext,
								  "MdSmgr",
								  ALLOCSET_DEFAULT_MINSIZE,
								  ALLOCSET_DEFAULT_INITSIZE,
								  ALLOCSET_DEFAULT_MAXSIZE);
@SmartKeyerror
Copy link
Contributor

The invocation of mdinit() in the last of function smgr_init_standard seems redundant.

@reshke I suppose we can remove it, what do you think?

@Aegeaner
Copy link
Contributor

Aegeaner commented Mar 1, 2023

We can consider making magnetic disk's smgr_init() a no-op function, as mdinit() is always there. Any thoughts?

.smgr_init = mdinit,

SmartKeyerror added a commit that referenced this issue Mar 2, 2023
…5091)

This PR is trying to fix the issue of #14561, we should not invoke mdinit()
directly at the end of the function smgr_init_standard().

No more tests are needed, cause current tests are enough to cover.
@SmartKeyerror
Copy link
Contributor

Fixed by #15091, close this issue. Please feel free to reopen this if the PR doesn't fix this problem completely.

@kainwen
Copy link
Contributor

kainwen commented Mar 2, 2023

Fixed by #15091, close this issue. Please feel free to reopen this if the PR doesn't fix this problem completely.

Need backport or not?

SmartKeyerror added a commit to SmartKeyerror/gpdb that referenced this issue Mar 2, 2023
…eenplum-db#15091)

This PR is trying to fix the issue of greenplum-db#14561, we should not invoke mdinit()
directly at the end of the function smgr_init_standard().

No more tests are needed, cause current tests are enough to cover.
@Aegeaner
Copy link
Contributor

Aegeaner commented Mar 2, 2023

Fixed by #15091, close this issue. Please feel free to reopen this if the PR doesn't fix this problem completely.

What if NSmgr>1? There will still be redudant mdinit() invocations as each smgr_init hook in the function array smgrsw was assigned by mdinit:

void
smgr_init_standard(void)
{
	int i;
	for (i = 0; i < NSmgr; i++)
	{
		if (smgrsw[i].smgr_init)
			smgrsw[i].smgr_init();
	}
}

static const f_smgr smgrsw[] = {
	/* magnetic disk */
	{
		.smgr_init = mdinit,
		……
	},
	/*
	 * Relation files that are different from heap, characterised by:
	 *     1. variable blocksize
	 *     2. block numbers are not consecutive
	 *     3. shared buffers are not used
	 * Append-optimized relation files currently fall in this category.
	 */
	{
		.smgr_init = mdinit,
                ……
	}
};

So there are still possible memory leaks.

@Aegeaner Aegeaner reopened this Mar 2, 2023
@SmartKeyerror
Copy link
Contributor

SmartKeyerror commented Mar 2, 2023

What if NSmgr>1?

The NSmgr will be 2 in the gpdb, since there have heap and AO table storage manager. For the design of storage manager, as many managers as there are, they should be invoked serval times.

@Aegeaner
Copy link
Contributor

Aegeaner commented Mar 2, 2023

What if NSmgr>1?

The NSmgr will be 2 in the gpdb, since there have heap and AO table storage manager. For the design of storage manager, as many managers as there are, they should be invoked serval times.

So the MemoryContext should be allocated twice even with the same name?

@SmartKeyerror
Copy link
Contributor

So the MemoryContext should be allocated twice even with the same name?

Maybe we should set the smgr_init of the storage manager of the AO table to NULL.

@ashwinstar
Copy link
Contributor

So the MemoryContext should be allocated twice even with the same name?

Maybe we should set the smgr_init of the storage manager of the AO table to NULL.

or might be better to just make mdinit re-entrant and avoid leak memory

SmartKeyerror added a commit that referenced this issue Mar 8, 2023
…5091) (#15108)

This is the backport of #15091

This PR is trying to fix the issue of #14561, we should not invoke mdinit() directly at
the end of the function smgr_init_standard().

No more tests are needed, cause current tests are enough to cover.
@ashwinstar
Copy link
Contributor

So the MemoryContext should be allocated twice even with the same name?

Maybe we should set the smgr_init of the storage manager of the AO table to NULL.

or might be better to just make mdinit re-entrant and avoid leak memory

@SmartKeyerror this part is still remaining to be addressed from this issue.

@SmartKeyerror
Copy link
Contributor

this part is still remaining to be addressed from this issue.

Did I miss something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants