Crash in virtual file descriptor FDDEBUG code

Started by Greg Nancarrowabout 5 years ago2 messages
#1Greg Nancarrow
gregn4422@gmail.com
1 attachment(s)

Hi Hackers,

While investigating a possible file-descriptor issue, I enabled the
FDDEBUG code in src/backend/storage/file/fd.c, only to find that it
resulted in a crash as soon as it was invoked.
It turns out the crash was in some logging code that was being passed
a NULL fileName.
I've attached a small patch that corrects the issue.

Regards,
Greg Nancarrow
Fujitsu Australia

Attachments:

v1-0001-Fix-crash-in-virtual-file-descriptor-FDDEBUG-code.patchapplication/octet-stream; name=v1-0001-Fix-crash-in-virtual-file-descriptor-FDDEBUG-code.patchDownload
From e719e320366c9bde8608b180bcf8a42481c3a89a Mon Sep 17 00:00:00 2001
From: Greg Nancarrow <gregn4422@gmail.com>
Date: Tue, 17 Nov 2020 10:43:27 +1100
Subject: [PATCH] Fix crash in virtual file descriptor FDDEBUG code.

When virtual file descriptor FDDEBUG code is enabled, a crash occurs
within the logging code in Insert(). This results from a NULL "fileName"
being passed by PathNameOpenFilePerm(). The correction is to move the
Insert() invocation until after fileName is set in the VfdCache entry.
---
 src/backend/storage/file/fd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c
index bd72a87..05abcf7 100644
--- a/src/backend/storage/file/fd.c
+++ b/src/backend/storage/file/fd.c
@@ -1486,8 +1486,6 @@ PathNameOpenFilePerm(const char *fileName, int fileFlags, mode_t fileMode)
 	DO_DB(elog(LOG, "PathNameOpenFile: success %d",
 			   vfdP->fd));
 
-	Insert(file);
-
 	vfdP->fileName = fnamecopy;
 	/* Saved flags are adjusted to be OK for re-opening file */
 	vfdP->fileFlags = fileFlags & ~(O_CREAT | O_TRUNC | O_EXCL);
@@ -1496,6 +1494,8 @@ PathNameOpenFilePerm(const char *fileName, int fileFlags, mode_t fileMode)
 	vfdP->fdstate = 0x0;
 	vfdP->resowner = NULL;
 
+	Insert(file);
+
 	return file;
 }
 
-- 
1.8.3.1

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Greg Nancarrow (#1)
Re: Crash in virtual file descriptor FDDEBUG code

Greg Nancarrow <gregn4422@gmail.com> writes:

While investigating a possible file-descriptor issue, I enabled the
FDDEBUG code in src/backend/storage/file/fd.c, only to find that it
resulted in a crash as soon as it was invoked.

Yeah, I can imagine that code doesn't get tested often.

I've attached a small patch that corrects the issue.

Thanks, will push.

BTW, while looking at this I started to cast an unfriendly eye on the
_dump_lru() debug function that's hidden under that symbol. That seems
like it's spending a lot of cycles to give you information that will
very possibly be incomplete (since its 2K buffer would fill up fast).
And it could very easily turn into an infinite loop if there were
anything actually wrong with the LRU chain. So I'm not seeing where
the cost-benefit ratio is there.

Maybe we should change it to just print the first and last entries
and the number of entries --- which it could count using a loop that
knows there shouldn't be more entries than the size of the VFD
array, so as to prevent infinite-looping if the chain is corrupt.

regards, tom lane