On Wed, Jul 04, 2012 at 04:17:39PM +0200, Wido den Hollander wrote: > > > On 04-07-12 14:08, Eric Blake wrote: > >[adding gnulib] > > > >On 07/04/2012 02:45 AM, Daniel P. Berrange wrote: > > > >>>>==6825== > >>>>==6825== Invalid read of size 4 > >>>>==6825== at 0xA57E4B9: base64_encode (in /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0) > >>>>==6825== by 0x10DDBC98: base64_encode_alloc (base64.c:140) > > > >>>> > >>>>This one is very interesting. It shows that the 'base64_encode' function > >>>>is doing an out-of-bounds read. More tellingly though is that it is > >>>>reporting 'base64_encode' function is in a wierd library: > >>>> > >>>> /usr/lib/x86_64-linux-gnu/libroken.so.18.1. > >>>> > >>>>If this were normal, we should expect to see that function present > >>>>in 'base64.c' since this function code is provided by gnulib itself. > >>>> > >>>>So something else libvirt is linking to, directly or indirectly > >>>>is using libroken.so which also has a 'base64_encode'symbol > >>>>defined. This is overriding gnulib's symbol of the same name. > >>>> > >>>>I'm willing to bet the API contract of this libroken.so base64_encode. > >>>>differs from GNULIBS, with crashtastic results > >>>> > > > >>>The library is libroken18-heimdal under Ubuntu 12.04: > >>>http://packages.ubuntu.com/precise/libroken18-heimdal > >>> > >>>When installing ubuntu-virt-server libraries like gnutls depend on > >>>this library. > >>> > > > >>I expect that this is an internal symbol from libroken.so which > >>they leak into the public namespace. > >> > > > >>It sounds like we might need to have a workaround in gnulib to > >>avoid this problem. With other cases where gnulib replaces existing > >>symbols they use some magic such that the gnulib replacement gets > >>prefixed with 'rpl_'. > > > >Yuck. Gnulib can't really probe at configure time whether an > >application will link against a shared library that drags in namespace > >pollution, so I don't see how to automate any 'rpl_' renaming in gnulib > >directly. It would be possible to blindly rename the gnulib functions, > >but that's an interface change that would affect all clients of the > >gnulib base64 module. > > > >I'm wondering if it is better for libvirt to just #define base64_encode > >to a different name in config.h. Meanwhile, we need to open a bug > >report against heimdal to fix their library namespace pollution through > >libroken. > > > > As this is getting a bit out of my league it's safe for me to assume > somebody else will pick this up? Yes, we'll sort it out from here. > Not to take the easy way out, but I don't think I can't provide much > help here other then testing any patches. I'll try to remember to let you know when we've got a possible fix. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list