Description of Problem:

When listing the open files of a process that has memory mapped a filename that 
is now unlinked (but the inode still exists because it is still open), lsof 
simply omits displaying the memory map. It should display the filename, the 
inode number, and mention that the file has been deleted.

Version-Release number of selected component (if applicable):

lsof-4.51-2 (red hat RPM)
(This RPM contains lsof-4.51 compiled with linux/proc data-getting)

How Reproducible:

Always.

Steps to Reproduce:
1. Find a long-running daemon process.
2. Upgrade a shared library.
3. Run lsof and compare with /proc/PID/maps

Actual Results:

# lsof -p 26226 | grep crypto
# cat /proc/26226/maps | grep crypto
40470000-40525000 r-xp 00000000 68:02 
34640      /lib/libcrypto.so.0.9.6b;3d5831be (deleted)
40525000-40531000 rw-p 000b4000 68:02 
34640      /lib/libcrypto.so.0.9.6b;3d5831be (deleted)


Expected Results:

Well, lsof should have listed /lib/libcrypto.so.0.9.6b and noted that it was a 
deleted file and listed the inode number of that deleted file.

This is now lsof deals with files opened on a file descriptor:

# lsof -p 18200 | head -1
COMMAND   PID USER   FD   TYPE DEVICE    SIZE   NODE NAME
# lsof -p 18200 | grep randomfile01
sleep   18200 root    1w   REG  104,2       0  69555 /tmp/randomfile01
# rm /tmp/randomfile01
#  lsof -p 18200 | grep randomfile01
sleep   18200 root    1w   REG  104,2       0  69555 /tmp/randomfile01 (deleted)

Additional Information:

For an additional idea of why things failed I ran a strace. You can see below 
that lsof is treating the pseuto-filename in /proc/PID/maps as a real filename, 
not parsing the deleted info, and trying to stat that filename. Apparently lsof 
ignores the filename when the stat fails.

# strace -o /tmp/strace-02 lsof -p 26226 | grep crypto
# grep libcrypto /tmp/strace-02
stat64("/lib/libcrypto.so.0.9.6b;3d5831be", 0xbfffc200) = -1 ENOENT (No such 
file or directory)