VMware freezes on GNOME "open" dialog

[xtknight]

I'm running Ubuntu 6 with GNOME 2.14.3. When I run VMware and try to specify an ISO for my virtual machine's CD-Rom device, the whole app freezes. This didn't used to happen. The File->Open menu doesn't work either. It just freezes the whole VMware Workstation application after releasing my mouse from "Open".

I notice this output from vmware stdout.

(vmware:12056): libgnomevfs-WARNING **: Cannot load module `/usr/lib/gnome-vfs-2.0/modules/libfile.so' (/usr/lib/gnome-vfs-2.0/modules/libfile.so: cannot open shared object file: No such file or directory)

This file exists. And from my user account I can do "ldd /usr/lib/gnome-vfs-2.0/modules/libfile.so" and it reports no missing libraries.

I have defragged my whole /home directory (xfs_fsr). Still fails. So I attached strace to it right before the crash (selecting the Browse button on the VM's CD-Rom device page).

strace -p pid

This is the end of the huge output I got. Can anyone decode this? The file->open freeze does not happen with any other GNOME application that I use. I am not using SMB or NFS either so I don't think it's a frozen mount.

vmware turns into a zombie when it crashes:

12416 pts/12 S+ 0:00 /bin/sh /usr/lib/vmware/lib/wrapper-gtk24.sh
/usr/lib12432 pts/12 Zl+ 0:02 [vmware] <defunct>
12433 pts/12 S+ 0:00 /bin/sh /usr/lib/vmware/lib/wrapper-gtk24.sh
/usr/lib12436 pts/12 Z+ 0:00 [vmware] <defunct>

 

[cleverhandle]

Maybe a 32-bit/64-bit problem? My VMWare (Server, which is 32-bit) seems to have some kind of logic built-in that decides whether or not to load the GTK libraries - mine is linked to a bunch of non-existent 32-bit GTK libs, but it functions fine. Maybe your VMWare is trying to load GTK libraries that it wasn't attempting to load before?

 

[xtknight]

Originally posted by: cleverhandle
Maybe a 32-bit/64-bit problem?

Apparently so. It runs fine with 'linux32 vmware' with tons of more errors, but not the same ones. And everything seems to work fine. Without using linux32, I copied the 32-bit libfile.so into my regular lib directory and then it said there was a problem with libfam. So I figured linux32 would just have it use the 32-bit library directories I already had intact. There is a libfile in /usr/lib32/gnome-vfs-2.0. Seemed to work fine with no freezes.

I thought the VMware GUI was 64-bit. Apparently not.

andy@ubuntu:/usr/lib/vmware/bin$ file vmware
vmware: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped

But the vmware kernel modules are 64-bit aren't they? I'll just use linux32 vmware from now on. Thanks for the clues. But the real question is why did it used to work? I don't recall messing with my library directories too much.

What does linux32 actually do? Can I just tell the program to look for LIBs in /usr/lib32 instead of actually running it with linux32? Not that that would gain me anything I guess. 😕 Doing sudo vmware-config.pl to reconfigure VMware doesn't fix it either.

 

[xtknight]

OK, I found something interesting. I start firefox32 (a 32-bit version of firefox packaged for Ubuntu 64) with the command firefox32, and I do file open, and guess what? Segfault. This one even segfaults with linux32 though I suppose that's because firefox32 is actually a script and I'm only running the script itself in 32-bit mode, not whatever the script is executing.

Running the firefox32 binary itself results in blocky characters (without pangohack).

Here's the firefox32 script:
export GTK_PATH=/usr/lib32/gtk-2.0
export LD_PRELOAD=/usr/lib32/libpangohack.so.0
linux32 /usr/local/firefox32/firefox $@

If I do the GTK_PATH line, I get a segfault. Without it, the firefox runs as expected with no crash on file->open. I'm going to reinstall all my 32-bit GTK libraries. Oh, I know what it could be. I did extract a bunch of 32-bit libs into my lib32 directory a couple days ago so maybe that did something.

Do you run a 64-bit with 32-bit VMware? Can you tell me the output of your "locate libfile.so"?

Here's mine:
andy@ubuntu:/usr/lib32$ locate libfile.so
/usr/lib/gnome-vfs-2.0/modules/libfile.so
/usr/lib32/gnome-vfs-2.0/modules/libfile.so
/data/usr/lib/gnome-vfs-2.0/modules/libfile.so

The /data is my 32-bit chroot which shouldn't even be accessed anyway but it's using the lib when it needs to use the lib32 for some reason, yet it used to work without linux32. Very odd.