SRU: vmware-guestd crashing
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
open-vm-tools (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Intrepid |
Invalid
|
Undecided
|
Unassigned |
Bug Description
The upstream version of open-vm-tools in Intrepid FTBFS because it has format string warnings and is built with -Werror. The Ubuntu “fix”, ubuntu_
The format string warnings have been fixed (correctly) upstream, so this patch is not needed in Jaunty and has already been removed. The attached debdiff (comment 22) fixes ubuntu_
This debdiff also fixes bug #289921 “network interface does not come up after installing open-vm-tools” and bug #302226 “vmware-user doesn't autostart”, and descriptions of the corresponding patches are posted there.
The patched package has been in my PPA for four weeks, and confirmed working by three other users. Risk of regression is low, especially given that these three bugs essentially prevent the current Intrepid package from being useful in any way.
===
Binary package hint: open-vm-tools
I have some amd64 machines running on VMWare ESX and the vmware-guestd terminates itself after a few seconds. The kernel modules load fine and while vmware-guestd is running the Infrastrcture Client shows that the VMWare Tools are running.
I used the latest version from -proposed:
open-vm-tools 2008.08.
linux-image-
I also attached the output of strace. I think the last few lines are interessting:
read(13, "Inter-| Receive "..., 1024) = 453
ioctl(12, SIOCGIFFLAGS, {ifr_name="lo", ifr_flags=
ioctl(12, SIOCGIFMTU, {ifr_name="lo", ifr_mtu=16436}) = 0
ioctl(12, SIOCGIFADDR, {ifr_name="lo", ifr_addr={AF_INET, inet_addr(
ioctl(12, SIOCGIFNETMASK, {ifr_name="lo", ifr_netmask=
ioctl(12, SIOCGIFFLAGS, {ifr_name="eth0", ifr_flags=
ioctl(12, SIOCGIFMTU, {ifr_name="eth0", ifr_mtu=1500}) = 0
ioctl(12, SIOCGIFADDR, {ifr_name="eth0", ifr_addr={AF_INET, inet_addr(
ioctl(12, SIOCGIFNETMASK, {ifr_name="eth0", ifr_netmask=
ioctl(12, SIOCGIFHWADDR, {ifr_name="eth0", ifr_hwaddr=
write(2, "str.c:100 Buffer too small 0x7f7"..., 34) = 34
write(2, "str.c:100 Buffer too small 0x7f7"..., 34) = 34
write(2, "Backtrace:\n", 11) = 11
futex(0x7f77aa2
write(2, "Backtrace[0] 00007fffb4853200 ri"..., 177) = 177
write(2, "Backtrace[1] 00007fffb4853220 ri"..., 177) = 177
write(2, "Backtrace[2] 00007fffb4853640 ri"..., 177) = 177
write(2, "Backtrace[3] 00007fffb4853720 ri"..., 177) = 177
write(2, "Backtrace[4] 00007fffb4853810 ri"..., 177) = 177
write(2, "Backtrace[5] 00007fffb48538a0 ri"..., 177) = 177
write(2, "Backtrace[6] 00007fffb4857900 ri"..., 177) = 177
write(2, "Backtrace[7] 00007fffb4857920 ri"..., 177) = 177
write(2, "Backtrace[8] 00007fffb4857bc0 ri"..., 177) = 177
write(2, "Backtrace[9] 00007fffb4857be0 ri"..., 177) = 177
write(2, "Backtrace[10] 00007fffb4857fe0 r"..., 178) = 178
write(2, "Backtrace[11] 00007fffb4858050 r"..., 178) = 178
write(2, "Backtrace[12] 00007fffb4858100 r"..., 178) = 178
write(2, "str.c:100 Buffer too small 0x7f7"..., 34) = 34
exit_group(-1) = ?
Process 31194 detached
Changed in open-vm-tools: | |
importance: | Undecided → Medium |
description: | updated |
Changed in open-vm-tools (Ubuntu): | |
status: | Confirmed → Fix Released |
Changed in open-vm-tools (Ubuntu Intrepid): | |
status: | New → Confirmed |
Looks like a crash in retrieving information from libdnet, used by the guestInfo subsystem in guestd.
Could you reproduce the bug and upload the dumped core as well as the guestd executable containing symbols? You may need to play with 'ulimit' to allow a core dump to be generated.