Thread: Crash in virtual file descriptor FDDEBUG code

Crash in virtual file descriptor FDDEBUG code

From
Greg Nancarrow
Date:
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

Attachment

Re: Crash in virtual file descriptor FDDEBUG code

From
Tom Lane
Date:
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