GNOME Bugzilla – Bug 681206
vmware remote console segfaults with updated glibmm2.4
Last modified: 2013-03-07 14:26:01 UTC
As originally reported here: https://bugs.mageia.org/show_bug.cgi?id=6707 The working version of glibmm2.4 is 2.25.5, it's broken in 2.32.0 in Mageia 2 as well as 2.33.3 in Mageia Cauldron. I don't know what version the breakage happened in, but I do know what code addition caused it. Copied from my Mageia bug: 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). libgdk_pixbuf2.0_0-loaders-png12 needs to be installed for this program. 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
+ Trace 230628
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.
Is this a correct description of what has happened? - You run plugins/bin/vmware-vmrc from vmware-vmrc-linux-x86-3.0.0-309851.xpi via plugins/vmware-vmrc. It segfaults in Gdk::Pixbuf::get_width(). - You do not suspect a fault in Gdk::Pixbuf::get_width(). - You switch to another version of libgdk_pixbuf2.0_0. - vmware-vmrc segfaults in sigc::slot_base::~slot_base(), called from Glib::OptionGroup::CppOptionEntry::release_c_arg(). - You suspect a fault in Glib::OptionGroup::CppOptionEntry::release_c_arg(). I get the impression that this is an example of memory corruption. Memory corruption can be caused by a fault just about anywhere in the program, perhaps in Glib::OptionGroup::CppOptionEntry::release_c_arg(), perhaps somewhere else. The code that you suspect (case G_OPTION_ARG_CALLBACK in release_c_arg()) was added as a result of bug 589197. The first unstable release with this code is glibmm 2.27.94. The bug description hints that vmware-vmrc can be built and run with glibmm 2.25.5. Then it does not use the new functionality added by bug 589197, and case G_OPTION_ARG_CALLBACK should never be reached. I've extracted the files from vmware-vmrc-linux-x86-3.0.0-309851.xpi and run the script plugins/vmware-vmrc without parameters. The first time it printed Configuring libraries for first use Configured ./libconf/etc/fonts/local.conf Configured ./libconf/etc/fonts/fonts.conf Configured ./libconf/etc/fonts/fonts.dtd Configured ./libconf/etc/gtk-2.0/gdk-pixbuf.loaders Configured ./libconf/etc/gtk-2.0/gtk.immodules Configured ./libconf/etc/gtk-2.0/Clearlooks.gtkrc Configured ./libconf/etc/gtk-2.0/gtkrc Configured ./libconf/etc/gtk-2.0/im-multipress.conf Configured ./libconf/etc/pango/pangorc Configured ./libconf/etc/pango/pangorc.toolchain Configured ./libconf/etc/pango/pango.modules Configured ./libconf/etc/pango/pangox.aliases Configured ./libconf/etc/pango/pango.modules.toolchain ./lib/wrapper-gtk24.sh: 20: ./lib/wrapper-gtk24.sh: 0: not found Configuration successful When I run it again, it prints nothing. It does not segfault. ??? How do I reproduce the segfault? My operating system is Linux Ubuntu 12.04. This is perhaps a silly question, but I'm not used to xpi files. Must I add it to Firefox, and run it from there, or what? Add some parameters to plugins/vmware-vmrc?
As I said, vmware-vmrc *works* with glibmm 2.25.5 where the G_OPTION_ARG_CALLBACK case code is not present. So I guess 2.27.94 was the version that introduced this code that causes the breakage. When you are running it and seeing nothing, it is segfaulting, you just don't see it. Getting the backtrace was a bit tricky. Basically what the plugins/vmware-vmcrc wrapper script does is add the directories for the bundled libraries (in plugins/lib) to the LD_LIBRARY_PATH and then runs plugins/bin/vmware-vmrc. So I did the same manually, started off LD_LIBRARY_PATH with /usr/lib and /lib, and then ran a loop appending each of the directories in plugins/lib to it, so that I could run plugins/bin/vmware-vmrc directly. Then I could use strace or gdb with it to see what it was doing, see the segfault, and ultimately get the backtrace. As far as libgdk_pixbuf2.0_0-loaders-png12 vs libgdk_pixbuf2.0_0-loaders-png15, libgdk_pixbuf2.0_0-loaders-png12 is the only version available on Mageia 1 where this is working. Also, looking at the strace output, it gets farther when libgdk_pixbuf2.0_0-loaders-png12 is available, so obviously this is the version this program is built for. After that, I wasn't shooting in the dark or "suspecting" things, I traced through the code and experimented with some modifications to determine exactly what was happening in the glibmm code and where it was going wrong. I determined that the "delete option_arg" line in the code I cited is where the error occurs. option_arg is not null, nor are the two things that are deleted inside of the destructor there. As I said, it just appears to be an invalid pointer. BTW, if you add some code to the OptionArgCallback destructor so that the compiler can't optimize it out, you'll see the segfault printed to the console even if you just run plugins/vmware-vmrc.
Is vmware-vmrc an open source program? I'd like to know what's going on in lui::OptionGroup::AddWithWrapper( Glib::ustring const&, char, int, Glib::ustring const&, Glib::ustring const&, GOptionArg, void*) () from ./lib/libvmwareui.so.0/libvmwareui.so.0 I suspect that lui::OptionGroup is a subclass of Glib::OptionGroup and that it writes to protected variables. That might be the reason why the program segfaults after functionality for G_OPTION_ARG_CALLBACK was added to Glib::OptionGroup.
(In reply to comment #3) > Is vmware-vmrc an open source program? Not that I'm aware of :o(
Yes, lui::OptionGroup is a subclass of Glib::OptionGroup and it writes to protected variables. This is as far as I get with gdb without access to the source code of lui::OptionGroup. Someone has obviously studied the source code of Glib::OptionGroup, and written a subclass that uses protected data in a way that works up to glibmm 2.27.93. When I added G_OPTION_ARG_CALLBACK functionality 2011-02-14 it stopped working. Strange that it hasn't been noticed until now. This functionality is included in stable release glibmm 2.28.0 since 2011-04-15. Or has it been noticed? Is there a newer release of vmware-vmrc than the 1-year old one at https://github.com/vmware/rvc/downloads? I haven't found a newer one. Who's to blame for this? What's in an API? Are application programs allowed to do what they want with protected data as long as it works with one particular version of glibmm? Did I break API when I fixed bug 589197? If necessary, I can try to get in contact with vmware and see if they are willing to modify their lui::OptionGroup class, but I won't do it now. I will very soon take a break from Gnome, and will return in about 2 weeks.
I have looked around, but I don't think there are any newer versions out there. My hope is that there is some way to work around this issue in glibmm.
I found some probably related information at http://kintoandar.blogspot.com/2011/06/gnome-3-vmware-console-with-vmware-vmrc.html As mentioned there, there is a workaround: export VMWARE_USE_SHIPPED_GTK=yes cd the_vmrc_directory/plugins ./vmware-vmrc # ./vmware-vmrc >/dev_null 2>&1 # if you want to suppress warnings. The downloaded file vmware-vmrc-linux-x86-3.0.0-309851.xpi contains compatible versions of glibmm, glib, gtk+, gtkmm, etc. Those versions are used if VMWARE_USE_SHIPPED_GTK=yes or VMWARE_USE_SHIPPED_GTK=force. It works only if the vmware-vmrc script is executed from its own directory. Otherwise the program crashes in Gdk::Pixbuf::get_width(). Possibly the program can't find its pictures in plugins/share/pixmaps (just my guess). It's easier than you might think to run plugins/bin/vmware-vmrc under gdb. Start the vmware-vmrc script with ./vmware-vmrc -G The parameter -G is decoded in plugins/lib/wrapper-gtk24.sh. Setting VMWARE_USE_SHIPPED_GTK=yes is just a workaround, and no real solution. I don't yet know if it would be possible to fix the bug in glibmm. To do that I will probably need the source code of vmware's lui::OptionGroup class, to see exactly what it's doing. But I don't like that idea. It would be better and probably easier (for someone with access to the source code) to fix it in lui::OptionGroup.
I have posted some questions to one of VMware's discussion forums, http://communities.vmware.com/community/vmtn/desktop/player, http://communities.vmware.com/message/2109059#2109059 I couldn't find a forum for vmware-vmrc.
No answer yet on the VMware Player forum. I've now also posted my questions on the VMware vCloud Director forum. http://communities.vmware.com/community/vmtn/server/vcd http://communities.vmware.com/message/2114818#2114818 I can't find a good way to ask technical questions to VMware without being their customer. I don't even know if the VMware folks read the messages on these forums.
On September 18 I got a reply from VMware, from a person who does not work with vmrc. He has made the vmrc group aware of my questions. So far I have got no response from anyone at VMware who works with vmrc. The version of vmrc at https://github.com/vmware/rvc/downloads is 2 years old. I wouldn't be surprised if there are newer versions available for those who pay for it.
There is indeed a newer version of VMRC. It's downloadable from the web interface of a current ESXi installation. With some quick Googling, I couldn't find it publicly available to download, but the installer that downloads from the web interface is called VMware-VMRC.i386.bundle. It does work with glibmm2.4 2.32.0.
I have got replies from VMware! It required a detour via a discussion on libsigc-list concerning an unrelated issue. Here are parts of the replies from Constantine Kousoulis: > I recall your attempt to get our attention about this via the vCloud > Directory forums: http://communities.vmware.com/thread/418153 > I'm glad you finally got to us, though it's a shame it took this long. > > For your reference, VMRC now has a public SDK with its own community on which > it's more likely that we would notice you > It's a good thing, cause now users of VMRC don't have to hide in the dark > anymore. > http://communities.vmware.com/community/vmtn/developer/forums/vmrc > I think you can close that bug. It has been reported that we've resolved the > issue and our latest releases use newer glibmm. > > At VMware, we'll keep track of three items. > 1. Replace usage of sigc::group(). > 2. If you, Christian, David identify that lui::OptionGroup is doing something > suspect, then we will fix that. > 3. Make 'rvc' use a non-ancient 'vmrc'. (I already opened this bug report > long ago when I saw 'rvc' available on github) > > Boring details: The VMRC product changed a bit from what it was when used in > 'rvc' to the web SDK for which we have the VMware community forums. The > important bit is that, if they ever release 'rvc' again, I'll make sure they > fix my bug against them to use a modern version of the remote console tool. (Item 1 concerns the unrelated issue on libsigc-list.) In summary: VMware-vmrc has been updated to work with new versions of glibmm. An updated version of vmrc will (probably?) be available at https://github.com/vmware/rvc/downloads in the future. You can download an updated version now from the vmrc community forum at http://communities.vmware.com/community/vmtn/developer/forums/vmrc In order to download you must register at VMware's site, though. If you don't like that, you can use the old version from github with the workaround described in comment 7 until a newer version becomes available on github. If you use some other product from VMware, there may be other ways to download vmrc, as mentioned in comment 11. Closing this bug. The bug has been fixed, but it was fixed by changing vmrc and not glibmm. Therefore I consider OBSOLETE a more appropriate resolution than FIXED.