Crash in virtual file descriptor FDDEBUG code

Started by Greg Nancarrowover 5 years ago2 messageshackers
Jump to latest
#1Greg Nancarrow
gregn4422@gmail.com

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+2-3
#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