Bug 1073760 - vmtoolsd process running as user aborts with segfault
vmtoolsd process running as user aborts with segfault
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Virtualization:Other
Current
x86-64 Other
: P5 - None : Major (vote)
: ---
Assigned To: Mike Latimer
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-12-21 01:06 UTC by Ron Lovell
Modified: 2018-05-20 20:47 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ron Lovell 2017-12-21 01:06:04 UTC
At startup, the vmtoolsd process running as the user (option -n vmusr) aborts with a segfault. From journal:

kernel: vmtoolsd[2650]: segfault at f0 ip 00007fb61c7a1232 sp 00007fff4e0b7bb8 error 4 in libgdk-3.so.0.2200.26[7fb61c758000+e

The vmtoolsd process running as root does start. I don't know how long this problem has been present. I happened to see it in Fedora Rawhide on 19 December and checked my other Linux VMs at that time.

I'm running my Linux VMs under VMware Workstation Player 14 hosted on Windows 7.

I'm running current Tumbleweed versions, including open-vm-tools 10.1.15-1.2. I noticed that TW will update to 10.2.0 soon. It might still be a problem there as well. Fedora has a bug 1526942 against open-vm-tools 10.2.0 for what appears to be the identical problem. Just for reference, I do NOT see the problem in Debian Sid (Unstable) running open-vm-tools 10.2.
Comment 1 Mike Latimer 2017-12-21 20:47:01 UTC
(Adding VMware to this bug due to the cross-distribution report.)

(In reply to Ron Lovell from comment #0)
> At startup, the vmtoolsd process running as the user (option -n vmusr)
> aborts with a segfault. From journal:
> 
> kernel: vmtoolsd[2650]: segfault at f0 ip 00007fb61c7a1232 sp
> 00007fff4e0b7bb8 error 4 in libgdk-3.so.0.2200.26[7fb61c758000+e

I've tested this under the latest Tumbleweed build (with open-vm-tools 10.1.15-1.2), and also SLES12SP3 and I cannot reproduce the problem. However, I'd like some details on how you are running `vmtoolsd -n vmusr`.

In a default installation that includes open-vm-tools-desktop, after logging into a graphical desktop environment, there should be two processes running:

# ps -ef | grep vmtoolsd
root   1062  1  0  12:57  ?   00:00.01  /usr/bin/vmtoolsd
mike   2483  1  0  12:58 tty7 00:00.01  /usr/bin/vmtoolsd -n vmusr --blockFd 3

The vmtoolsd process owned by root is started automatically during system startup (through the vmtoolsd service). The 'vmtoolsd -n vmusr' process owned by 'mike' is started after I log into the graphical desktop environment. The process that starts this is the vmware-user-autostart.desktop config file, which ultimately executes /usr/bin/vmware-user-suid-wrapper. If you are not starting `vmtoolsd -n vmusr` in this way, I'd like details on how you are starting (and why).

> I'm running my Linux VMs under VMware Workstation Player 14 hosted on
> Windows 7.

I'm testing this under an older version of VMware Workstation. I can try ESX later, but I don't think this would be a problem on the side of the host...

> I'm running current Tumbleweed versions, including open-vm-tools
> 10.1.15-1.2. I noticed that TW will update to 10.2.0 soon. It might still be
> a problem there as well. Fedora has a bug 1526942 against open-vm-tools
> 10.2.0 for what appears to be the identical problem. Just for reference, I
> do NOT see the problem in Debian Sid (Unstable) running open-vm-tools 10.2.

That's interesting. Maybe VMware might have some comments here.
Comment 2 Ron Lovell 2017-12-22 14:17:44 UTC
(In reply to Mike Latimer from comment #1)

Hi Mike,
Thanks for the quick reply. Let me correct an error first: The Fedora Bug is 1526952, not 1526942 as I wrote.

> However, I'd like some details on how you are running `vmtoolsd -n vmusr`.

I'm not doing anything special, so /etc/xdg/autostart/vmware-user-autostart.desktop is presumably starting the per-user vmtoolsd. I see its last access time is exactly when I logged into GNOME yesterday.

New results: I just logged into GNOME with X11 session, and the per-user vmtoolsd process starts successfully. Output of ps:

lovells@ron5tum:~$ ps -ef | grep vmtools
root      1067     1  0 Dec21 ?        00:01:31 /usr/bin/vmtoolsd
lovells  24535     1  0 08:11 tty2     00:00:00 /usr/bin/vmtoolsd -n vmusr --blockFd 3

Considering the backtraces shown in Red Hat Bug 1526952, this is beginning to have the feel of a graphics situation that occurs in Wayland sessions that vmtoolsd does not handle gracefully.
Comment 3 Mike Latimer 2017-12-22 18:20:36 UTC
(In reply to Ron Lovell from comment #2)
> Considering the backtraces shown in Red Hat Bug 1526952, this is beginning
> to have the feel of a graphics situation that occurs in Wayland sessions
> that vmtoolsd does not handle gracefully.

Yes, I just duplicated the problem after switching to Wayland on my test box. I also upgraded to 10.2.0 and still saw the problem:

#sudo coredumpctl dump
           PID: 2149 (vmtoolsd)
           UID: 1000 (mlatimer)
           GID: 100 (users)
        Signal: 11 (SEGV)
     Timestamp: Fri 2017-12-22 11:06:59 MST (2min 54s ago)
  Command Line: /usr/bin/vmtoolsd -n vmusr --blockFd 3
    Executable: /usr/bin/vmtoolsd
 Control Group: /user.slice/user-1000.slice/session-1.scope
          Unit: session-1.scope
         Slice: user-1000.slice
       Session: 1
     Owner UID: 1000 (mlatimer)
       Boot ID: f031430e7d6544148a8b662ad2dedc83
    Machine ID: e63fac42f89c4a3e968d9649b158679e
      Hostname: localhost
       Storage: /var/lib/systemd/coredump/core.vmtoolsd.1000.f031430e7d6544148a8b662ad2dedc83.2149.1513966019000000.lz4
       Message: Process 2149 (vmtoolsd) of user 1000 dumped core.

# gdb /usr/bin/vmtoolsd core.out
Core was generated by `/usr/bin/vmtoolsd -n vmusr --blockFd 3'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f3c09a14232 in gdk_window_has_impl (window=<optimized out>)
    at gdkwindow.c:677
677     gdkwindow.c: No such file or directory.
[Current thread is 1 (Thread 0x7f3c0ecde780 (LWP 2149))]
(gdb) bt
#0  0x00007f3c09a14232 in gdk_window_has_impl (window=<optimized out>)
    at gdkwindow.c:677
#1  _gdk_window_has_impl (window=window@entry=0x0) at gdkwindow.c:678
#2  0x00007f3c09a4b63e in gdk_x11_window_get_xid (window=0x0) at gdkwindow-x11.c:5560
#3  0x00007f3c0a92275d in X11Lock_Init ()
   from /usr/lib64/open-vm-tools/plugins/vmusr/libdesktopEvents.so
#4  0x00007f3c0a9224ab in ToolsOnLoad ()
   from /usr/lib64/open-vm-tools/plugins/vmusr/libdesktopEvents.so
#5  0x000055f469c17318 in ToolsCore_LoadPlugins ()
#6  0x000055f469c15fa3 in ToolsCoreRunLoop ()
#7  0x000055f469c15398 in main ()

As Ravindra is already working on this in the Fedora bug, I'll set needinfo to him. If anything is needed from my environment, I'd be happy to provide it.
Comment 4 Ravindra Kumar 2017-12-28 20:39:41 UTC
The problem is some of the plugins in open-vm-tools have not been updated/modified to work with Wayland yet. While we work on this transition from X11 to Wayland, we are in the process of creating a patch to workaround this limitation in our plugins in the meantime. We will publish the patch once it goes through reviews and testing.
Comment 5 Ron Lovell 2018-01-01 01:03:58 UTC
Fedora have pushed a fix in their 10.2.0-3 build. Works on my Rawhide VM running under VMware Workstation Player 14.
Comment 6 Ravindra Kumar 2018-01-02 18:47:24 UTC
Thanks Ron. Here is the link to the patch we have applied in Fedora:

https://src.fedoraproject.org/rpms/open-vm-tools/c/fec5bc0e046ed3f7f3563fca3ea41ba8e31cf406?branch=master

We will be releasing similar patch on github soon.
Comment 7 vmware gos 2018-03-13 06:09:01 UTC
VMware internal PR 2068986
--
Ruishuang Wang, VMware GOSV QE
Comment 8 Mike Latimer 2018-05-18 18:08:33 UTC
(In reply to Ravindra Kumar from comment #6)
> Thanks Ron. Here is the link to the patch we have applied in Fedora:
> 
> https://src.fedoraproject.org/rpms/open-vm-tools/c/
> fec5bc0e046ed3f7f3563fca3ea41ba8e31cf406?branch=master
> 
> We will be releasing similar patch on github soon.

This patch is included in 10.2.5, which was just accepted to Tumbleweed. The next build of TW will include this, and this bug should be safe to close.
Comment 9 Ron Lovell 2018-05-20 20:47:53 UTC
open-vm-tools-desktop 10.2.5-1.1 does fix the problem on my TW system. Thanks, guys!