On Wed, Jul 04, 2012 at 06:08:59AM -0600, 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.
Yeah, that's sort of what I was imagining we could do in base64.h in fact. If its better to just do it in libvirt config.h, then we can do that too 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 :|