lsof, libgtop2: 'struct rb_entry' has no member named 'rbe_left' etc

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

lsof, libgtop2: 'struct rb_entry' has no member named 'rbe_left' etc

Stuart Henderson
Any suggestions what to do in the short term about these kvm-grovellers?
lsof isn't so important, the only port depending on it is a tor connection
monitor thingy, libgtop2 affects more things, but the fix is likely to be
the same for both.


In file included from /usr/include/uvm/uvm.h:42,
                 from procmap.c:51:
/usr/include/uvm/uvm_pmemrange.h:130: warning: data definition has no type or storage class
/usr/include/uvm/uvm_pmemrange.h:130: warning: parameter names (without types) in function declaration
/usr/include/uvm/uvm_pmemrange.h:131: warning: data definition has no type or storage class
/usr/include/uvm/uvm_pmemrange.h:131: warning: parameter names (without types) in function declaration
/usr/include/uvm/uvm_pmemrange.h:133: warning: data definition has no type or storage class
/usr/include/uvm/uvm_pmemrange.h:133: warning: parameter names (without types) in function declaration
procmap.c: In function 'load_vmmap_entries':
procmap.c:113: error: 'struct rb_entry' has no member named 'rbe_left'
procmap.c:114: error: 'struct rb_entry' has no member named 'rbe_right'
procmap.c:115: error: 'struct rb_entry' has no member named 'rbe_left'
procmap.c:116: error: 'struct rb_entry' has no member named 'rbe_right'
procmap.c:118: error: 'struct rb_entry' has no member named 'rbe_parent'
procmap.c:131: error: 'struct rb_entry' has no member named 'rbe_left'
procmap.c:135: error: 'struct rb_entry' has no member named 'rbe_right'

etc.etc.

Reply | Threaded
Open this post in threaded view
|

Re: lsof, libgtop2: 'struct rb_entry' has no member named 'rbe_left' etc

Stuart Henderson
On 2016/09/20 14:22, Stuart Henderson wrote:

> Any suggestions what to do in the short term about these kvm-grovellers?
> lsof isn't so important, the only port depending on it is a tor connection
> monitor thingy, libgtop2 affects more things, but the fix is likely to be
> the same for both.
>
>
> In file included from /usr/include/uvm/uvm.h:42,
>                  from procmap.c:51:
> /usr/include/uvm/uvm_pmemrange.h:130: warning: data definition has no type or storage class
> /usr/include/uvm/uvm_pmemrange.h:130: warning: parameter names (without types) in function declaration
> /usr/include/uvm/uvm_pmemrange.h:131: warning: data definition has no type or storage class
> /usr/include/uvm/uvm_pmemrange.h:131: warning: parameter names (without types) in function declaration
> /usr/include/uvm/uvm_pmemrange.h:133: warning: data definition has no type or storage class
> /usr/include/uvm/uvm_pmemrange.h:133: warning: parameter names (without types) in function declaration
> procmap.c: In function 'load_vmmap_entries':
> procmap.c:113: error: 'struct rb_entry' has no member named 'rbe_left'
> procmap.c:114: error: 'struct rb_entry' has no member named 'rbe_right'
> procmap.c:115: error: 'struct rb_entry' has no member named 'rbe_left'
> procmap.c:116: error: 'struct rb_entry' has no member named 'rbe_right'
> procmap.c:118: error: 'struct rb_entry' has no member named 'rbe_parent'
> procmap.c:131: error: 'struct rb_entry' has no member named 'rbe_left'
> procmap.c:135: error: 'struct rb_entry' has no member named 'rbe_right'
>
> etc.etc.
>

BTW here are the others pulling in libkvm, though the above are the only
two that got broken recently.

$ sqlite3 /usr/local/share/sqlports "select FULLPKGPATH from WANTLIB where value='kvm';"
comms/lcdproc
databases/mongodb
databases/pg_statsinfo
devel/gdb
devel/libgtop2
devel/xulrunner/24,-devel
devel/xulrunner/24,-main
lang/erlang/18,-main
lang/erlang/19,-main
lang/moarvm
lang/node
lang/rakudo
net/dnscrypt-proxy,-main
net/dnscrypt-proxy,-plugins
net/gnugk
net/ifmcstat
net/lldpd,snmp
net/miniupnp/miniupnpd
net/net-snmp,-main
net/zabbix,-main
net/zabbix,mysql,-main
net/zabbix,mysql,-server
net/zabbix,pgsql,-main
net/zabbix,pgsql,-server
net/zabbix,sqlite3,-main
net/zabbix,sqlite3,-server
security/lastpass-cli
sysutils/collectd,-main
sysutils/conky
sysutils/conky,no_x11
sysutils/conky,xmms2
sysutils/consolekit
sysutils/dtpstree
sysutils/gkrellm/gkrellm,-client
sysutils/gkrellm/gkrellm,-main
sysutils/monit
sysutils/p5-Proc-ProcessTable
sysutils/pscpug
sysutils/py-psutil
sysutils/py-psutil,python3
sysutils/whowatch
sysutils/wmmon
sysutils/xps
telephony/asterisk,-snmp
telephony/asterisk,imap,-snmp
www/ruby-passenger
www/ruby-passenger,ruby22
www/ruby-passenger,ruby23
x11/gnome/bijiben
x11/gnome/control-center
x11/gnome/documents
x11/gnome/grilo-plugins
x11/gnome/nautilus
x11/gnome/online-miners
x11/gnome/photos
x11/gnome/system-monitor
x11/gnome/tracker
x11/kde4/workspace
x11/windowmaker,-main
x11/xfce4/xfce4-systemload

Reply | Threaded
Open this post in threaded view
|

Re: lsof, libgtop2: 'struct rb_entry' has no member named 'rbe_left' etc

Theo de Raadt-2
In reply to this post by Stuart Henderson
> Any suggestions what to do in the short term about these kvm-grovellers?
> lsof isn't so important, the only port depending on it is a tor connection
> monitor thingy, libgtop2 affects more things, but the fix is likely to be
> the same for both.

the rather ugly solution may be to link that tree code into libkvm.

the RIGHT solution would be for some unidentified person to go on a mission,
converting these utilities to use the sysctl interfaces, and stop snooping
kvm.

Reply | Threaded
Open this post in threaded view
|

Re: lsof, libgtop2: 'struct rb_entry' has no member named 'rbe_left' etc

Christian Weisgerber
In reply to this post by Stuart Henderson
On 2016-09-20, Stuart Henderson <[hidden email]> wrote:

> Any suggestions what to do in the short term about these kvm-grovellers?

I move that we delete lsof.  It has been building fine on the
amd64.ports machines and I was mystified how this could be until I
realized that it uses /usr/src/sys and I hadn't updated src.  Crazy.

I don't know about libgtop2.  Somebody should figure out what its
consumers actually need; maybe the kvm groveling can be replaced
by a dummy function.  I'm not volunteering, though.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lsof, libgtop2: 'struct rb_entry' has no member named 'rbe_left' etc

Stuart Henderson
On 2016/09/20 19:40, Christian Weisgerber wrote:
> On 2016-09-20, Stuart Henderson <[hidden email]> wrote:
>
> > Any suggestions what to do in the short term about these kvm-grovellers?
>
> I move that we delete lsof.  It has been building fine on the
> amd64.ports machines and I was mystified how this could be until I
> realized that it uses /usr/src/sys and I hadn't updated src.  Crazy.

I'm OK with this. net/arm will break; the diff below *might* fix that,
but I'm not particularly interested in running tor to test it.

> I don't know about libgtop2.  Somebody should figure out what its
> consumers actually need; maybe the kvm groveling can be replaced
> by a dummy function.  I'm not volunteering, though.

+1

Index: Makefile
===================================================================
RCS file: /cvs/ports/net/arm/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile 7 May 2016 12:40:58 -0000 1.5
+++ Makefile 21 Sep 2016 09:47:04 -0000
@@ -4,7 +4,7 @@ COMMENT = terminal status monitor for T
 
 V = 1.4.5.0
 DISTNAME = arm-${V}
-REVISION = 2
+REVISION = 3
 
 SUBST_VARS += V
 
@@ -22,7 +22,6 @@ EXTRACT_SUFX = .tar.bz2
 
 MODULES = lang/python
 RUN_DEPENDS = net/tor \
- sysutils/lsof \
  devel/desktop-file-utils
 
 NO_TEST = Yes
Index: patches/patch-src_util_connections_py
===================================================================
RCS file: patches/patch-src_util_connections_py
diff -N patches/patch-src_util_connections_py
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_util_connections_py 21 Sep 2016 09:47:04 -0000
@@ -0,0 +1,48 @@
+$OpenBSD$
+--- src/util/connections.py.orig Wed May  4 08:19:00 2016
++++ src/util/connections.py Wed May  4 08:31:16 2016
+@@ -70,6 +70,9 @@ RUN_SOCKSTAT = "sockstat | egrep \"%s *%s.*ESTABLISHED
+ RUN_BSD_SOCKSTAT = "sockstat -4c | grep '%s *%s'"
+ RUN_BSD_PROCSTAT = "procstat -f %s | grep TCP | grep -v 0.0.0.0:0"
+
++# userid   procname   81514    8* internet stream tcp 0x0 10.15.5.2:15876 --> 10.15.5.90:12345
++RUN_BSD_FSTAT = "fstat | grep -E '%s *%s.*internet6? stream tcp .* --> '"
++
+ RESOLVERS = []                      # connection resolvers available via the singleton constructor
+ RESOLVER_FAILURE_TOLERANCE = 3      # number of subsequent failures before moving on to another resolver
+ RESOLVER_SERIAL_FAILURE_MSG = "Unable to query connections with %s, trying %s"
+@@ -207,6 +210,7 @@ def getResolverCommand(resolutionCmd, processName, pro
+   elif resolutionCmd == Resolver.SOCKSTAT: return RUN_SOCKSTAT % (processName, processPid)
+   elif resolutionCmd == Resolver.BSD_SOCKSTAT: return RUN_BSD_SOCKSTAT % (processName, processPid)
+   elif resolutionCmd == Resolver.BSD_PROCSTAT: return RUN_BSD_PROCSTAT % processPid
++  elif resolutionCmd == Resolver.BSD_FSTAT: return RUN_BSD_FSTAT % (processName, processPid)
+   else: raise ValueError("Unrecognized resolution type: %s" % resolutionCmd)
+
+ def getConnections(resolutionCmd, processName, processPid = ""):
+@@ -272,6 +276,9 @@ def getConnections(resolutionCmd, processName, process
+       elif resolutionCmd == Resolver.BSD_PROCSTAT:
+         localIp, localPort = comp[9].split(":")
+         foreignIp, foreignPort = comp[10].split(":")
++      elif resolutionCmd == Resolver.BSD_FSTAT:
++        localIp, localPort = comp[9].split(":")
++        foreignIp, foreignPort = comp[11].split(":")
+      
+       conn.append((localIp, localPort, foreignIp, foreignPort))
+    
+@@ -337,12 +344,14 @@ def getSystemResolvers(osType = None):
+  
+   if osType == "FreeBSD":
+     resolvers = [Resolver.BSD_SOCKSTAT, Resolver.BSD_PROCSTAT, Resolver.LSOF]
+-  elif osType in ("OpenBSD", "Darwin"):
++  elif osType == "OpenBSD":
++    resolvers = [Resolver.BSD_FSTAT]
++  elif osType == "Darwin":
+     resolvers = [Resolver.LSOF]
+   else:
+     resolvers = [Resolver.NETSTAT, Resolver.SOCKSTAT, Resolver.LSOF, Resolver.SS]
+  
+-  # proc resolution, by far, outperforms the others so defaults to this is able
++  # proc resolution, by far, outperforms the others so defaults to this if able
+   if procTools.isProcAvailable():
+     resolvers = [Resolver.PROC] + resolvers
+