#2 Crash with NFS4

v1.0 (example)
closed
nobody
None
5
2016-01-07
2012-09-19
onlyjob
No

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.

Discussion

  • Stefan Paletta

    Stefan Paletta - 2013-06-15

    The attached patch fixes the crash and – while at it – we actually parse the correct lines ...

    Best regards
    –Stefan

     
    • onlyjob

      onlyjob - 2013-07-01

      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
      • Stefan Paletta

        Stefan Paletta - 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.

         
  • onlyjob

    onlyjob - 2013-07-01

    My bad, sorry for not paying enough attention to file. Here is backtrace with patch applied:

    #0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
    #1  0x000055555556649f in proc_nfs () at lmon.c:1477 same way every time
    #2  0x000055555555a98b in main (argc=<optimized out>, argv=<optimized out>) at lmon.c:4896
    

    Contents of "/proc/net/rpc/nfs":

    net 0 0 0 0
    rpc 4536625 38 4536625
    proc4 53 0 438752 113303 4867 225132 880 0 8 199310 95259 9 35845 7 7 220 1 192 178367 2618646 260449 2 78418 53320 1011 33759 1460 7 33410 531 36241 16 127060 20 20 0 94 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    
     
  • Stefan Paletta

    Stefan Paletta - 2013-07-02

    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.

     
  • onlyjob

    onlyjob - 2013-07-03

    Many thanks Stefan, your patch is working well for me. Well done. :)

     
  • Nigel Griffiths

    Nigel Griffiths - 2013-07-03

    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.

     
  • onlyjob

    onlyjob - 2013-07-03

    Thanks for the great news, Nigel.

     
  • Nigel Griffiths

    Nigel Griffiths - 2013-07-03

    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

     
  • onlyjob

    onlyjob - 2013-07-04

    nmon14h works well for me, thanks. IMHO we can close this bug.

     
  • Stefan Paletta

    Stefan Paletta - 2013-07-04

    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

     
  • Nigel Griffiths

    Nigel Griffiths - 2016-01-07

    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

     
  • Nigel Griffiths

    Nigel Griffiths - 2016-01-07
    • status: open --> closed
    • Group: --> v1.0 (example)
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks