Bug 6707

Summary:	vmware remote console segfaults in Mageia 2
Product:	Mageia	Reporter:	David Walser <luigiwalser>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	Normal	CC:	dmorganec, fundawang, olav, stormi-mageia
Version:	2
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:	glibmm2.4-2.32.0-1.mga2.src.rpm	CVE:
Status comment:

Description David Walser 2012-07-05 22:22:24 CEST

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

David Walser 2012-07-05 22:22:36 CEST

CC: (none) => olav

David Walser 2012-07-05 22:22:50 CEST

CC: (none) => fundawang

David Walser 2012-07-05 22:22:58 CEST

CC: (none) => jani.valimaa

David Walser 2012-07-05 22:23:04 CEST

CC: (none) => dmorganec

Comment 1 David Walser 2012-07-05 22:23:48 CEST

It works fine on Mageia 1 BTW.

Jani Välimaa 2012-07-29 16:34:02 CEST

CC: jani.valimaa => (none)

Comment 2 David Walser 2012-08-02 17:34:06 CEST

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.valimaa
Source 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

Comment 3 David Walser 2012-08-02 19:04:38 CEST

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.

Jani Välimaa 2012-08-08 21:39:56 CEST

CC: jani.valimaa => (none)

Comment 4 David Walser 2012-12-06 17:24:41 CET

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

Comment 5 Samuel Verschelde 2013-08-29 15:46:54 CEST

So, is there a bug in glibmm2.4 or is it just that you need to use recent vmware?

Keywords: (none) => NEEDINFO
CC: (none) => stormi

Comment 6 David Walser 2013-08-29 16:29:02 CEST

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 => RESOLVED
Resolution: (none) => WONTFIX