14g crashes when I press 'N' to bring NFS4 statistics on Debian Linux x86_64.
Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32
../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
Backtrace:
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32
#1 0x000055555555a5fb in proc_nfs () at lmon.c:1519 same way every time
#2 0x000055555556947e in main (argc=1, argv=0x7fffffffe178) at lmon.c:4896
Contents of /proc/net/rpc/nfsd:
rc 0 0 0
fh 0 0 0 0 0
io 0 0
th 0 0 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
ra 0 0 0 0 0 0 0 0 0 0 0 0
net 0 0 0 0
rpc 0 0 0 0 0
proc4ops 59 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Thank you.
The attached patch fixes the crash and – while at it – we actually parse the correct lines ...
Best regards
–Stefan
Thanks for patch but it needs further improvement.
Merely changing hard-coded line numbers is repeating the same mistake that lead to this problem in first place. For instance your patch doesn't even fix crash with sample "/proc/net/rpc/nfsd" as quoted in this bug report...
Last edit: onlyjob 2013-07-01
The primary concern of my patch was to parse the correct files (P_NFS vs. P_NFSD – look closely). It’s obvious that as the code was (wrongly) addressing P_NFS, the contents of P_NFSD didn’t have anything to do with the crash in the first place.
If you see any current crashes with the patch applied, please provide a backtrace and contents of the offending file.
My bad, sorry for not paying enough attention to file. Here is backtrace with patch applied:
Contents of "/proc/net/rpc/nfs":
I have reworked all of the nfs / nfsd related parsing code to remove assumptions about what lines are present and in what order. Apply the attached patch against a pristine lmon14g.c.
Many thanks Stefan, your patch is working well for me. Well done. :)
Hi, I just found out my two emails on this bounced. I works a fix that looks pretty much like the one from Stefan Palette. Actually, pretty spooky how similar! I also did the same for both NFS client and server sides so that one does not catch us later with some other Linux distro/version/platform/driver/config. I have also included another fix. Will be releasing this as nmon for Linux 14h.
Thanks for the great news, Nigel.
OK I released it - source forge has got lots better since the previous nmon release. If you can give it a quick test then we can close the bug. Cheers, Nigel Griffiths
nmon14h works well for me, thanks. IMHO we can close this bug.
Well, excuse me for being somewhat blunt, but the devil is in the details here: while comparing 5 characters in lines 1460, 1471, 1482, 1510, 1521, 1532 does work, it is not actually correct, because what you mean is to check the first token on the line, and so you would have to include the whitespace and compare 6 chars as I did. In the case of line 1532 it’s actually a regression – you mean to compare 8 chars at least, but limit to 5.
Unifying strlen() calls and moving assignments to nfs_vXY_found out of the loops is a matter of style arguably.
You also changed the indentation of the whole file from tabs to spaces. That was intentional?
Thanks
–Stefan
NFS code reworked since this bug - going to close it now.
Please create a new bug if you find the problem still there is nmon 16b or higher