vmware remote console is a program used to connect to VMWare ESX servers and open the console for VMs. It comes inside of an XPI for Firefox, which can be downloaded from here: https://github.com/vmware/rvc/downloads vmware-vmrc-linux-x86-3.0.0-309851.xpi is the package I am using. There are ones there for x86_64 as well, plus some redundant ones (like a zip and a tar.bz2). It is run by a script plugins/vmware-vmrc inside of that, which sets up some environment variables and then runs a binary (plugins/bin/vmware-vmrc). It seems that libgdk_pixbuf2.0_0-loaders-png12 needs to be installed for this (even though it still doesn't work either way), because if you only have libgdk_pixbuf2.0_0-loaders-png15, it segfaults in that library. Here's the top of the backtrace from that case: Program received signal SIGSEGV, Segmentation fault. 0xb71869e3 in Gdk::Pixbuf::get_width() const () from /usr/lib/libgdkmm-2.4.so.1 (gdb) bt #0 0xb71869e3 in Gdk::Pixbuf::get_width() const () from /usr/lib/libgdkmm-2.4.so.1 If you have libgdk_pixbuf2.0_0-loaders-png12 installed, it gets farther, but then segfaults in the Glib OptionGroup destructor. Here's the top of the backtrace from that case: Program received signal SIGSEGV, Segmentation fault. sigc::slot_base::~slot_base (this=0x53e58955, __in_chrg=<optimized out>) at functors/slot_base.cc:123 123 if (rep_) (gdb) bt #0 sigc::slot_base::~slot_base (this=0x53e58955, __in_chrg=<optimized out>) at functors/slot_base.cc:123 #1 0xb724f345 in ~slot3 (this=0x53e58955, __in_chrg=<optimized out>) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:648 #2 ~slot (this=0x53e58955, __in_chrg=<optimized out>) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:1198 #3 ~OptionArgCallback (this=0x8131b90, __in_chrg=<optimized out>) at optiongroup.cc:67 #4 Glib::OptionGroup::CppOptionEntry::release_c_arg (this=0x86f9b04) at optiongroup.cc:690 #5 0xb724f40b in Glib::OptionGroup::~OptionGroup (this=0xbfffdc90, __in_chrg=<optimized out>) at optiongroup.cc:303
CC: (none) => olav
CC: (none) => fundawang
CC: (none) => jani.valimaa
CC: (none) => dmorganec
It works fine on Mageia 1 BTW.
CC: jani.valimaa => (none)
OK, I've narrowed it down. The problem is definitely with glibmm2.4. I installed libglibmm2.4_1 from Mageia 1 on Mageia 2 and it works! I also built and installed the glibmm2.4 from Cauldron on Mageia 2 (required updated glib2.0 as well), and it doesn't work, so this problem still exists in the version in Cauldron.
CC: (none) => jani.valimaaSource RPM: glibmm2.4-2.32.0-1.mga2.src.rpm, libsigc++2.0-2.2.10-2.mga2.src.rpm => glibmm2.4-2.32.0-1.mga2.src.rpm
OK, I found the code change that causes the breakage. In glib/glibmm/optiongroup.cc, in release_c_arg(), this code was added at the end of the switch-case: case G_OPTION_ARG_CALLBACK: { // Delete the OptionArgCallback instance that was allocated by add_entry() // or add_entry_filename(). OptionArgCallback* option_arg = static_cast<OptionArgCallback*>(cpparg_); delete option_arg; cpparg_ = 0; break; } It appears that option_arg is an invalid pointer that it is trying to free, and if you remove that line of code or this whole block, everything works again.
As I noted on the upstream bug report, there is a newer version of VMRC that can be downloaded from the web interface of the newer ESXi version, and it does work with our glibmm2.4: https://bugzilla.gnome.org/show_bug.cgi?id=681206#c11
So, is there a bug in glibmm2.4 or is it just that you need to use recent vmware?
Keywords: (none) => NEEDINFOCC: (none) => stormi
Well, I don't think a change in a library should cause that kind of regression, but gnome upstream decided to let vmware upstream deal with it. On their bug they linked to a newer version of vmrc that can be downloaded from vmware, which doesn't work at all. The version I can get at work through our local ESXi server does work, so I'll mark this WONTFIX.
Keywords: NEEDINFO => (none)Status: NEW => RESOLVEDResolution: (none) => WONTFIX