[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha8-154-g826ee30

[simo]

On Thu, 2009-07-02 at 22:58 +1000, tridge at samba.org wrote:
> Hi Simo,
> 
>  > You can't have the 2 libraries installed at the same time.
> 
> huh?

I meant, you can't do it without risks, of course you can physically
drop in a file.

>  > If, through dependencies, both get loaded in the same process space, and
>  > both use the same symbol names, you are doomed.
> 
> err .. the loader is supposed to sort that out and use one. Metze has
> explained that it can screw up (though I don't fully understand how),
> and has proposed a patch that catches it if it happens. I certainly
> don't mind putting in that patch as a extra precaution.

This is how it can happen:
App A links talloc.so.1 and libsmbclient
New libsmbclient links talloc.so.2

At load time glibc loads talloc.so.1 into app A, then it loads
libsmbclient, which loads talloc.so.2
Now, most symbols are resolved by talloc.so.1 so glibc does not replace
them. A few new symbols though are not available so it loads them.
Simple and devastating.

>  > Can I ask you a question in reverse ?
>  > Why is it so imperative for you to break the ABI ?
>  > Why can't we fix the bug without breaking it ?
>  > I didn't see anything in this bug that couldn't be fixed and yet
>  > maintain the original ABI intact.
> 
> The ABI change is needed to give us sane logging so we can find the
> bugs we have that have crept in over the years because we had an
> ambiguous API. That logging has found about 10 bugs so far (Andrew
> used it to find another one today, when running a RPC test against
> w2k3).

I understand why you did the changes, nobody claims they are inherently
wrong.

> If you can propose a way to do this with no ABI change then please
> propose a patch (and please don't just re-send Sam's patch, I'll
> address that in a separate email).

Attached a possible patch.
NOTE: I am not proposing to push this one, it compiles and should work,
but I want to make a few tests on a system using this new talloc with an
old samba to confirm it really works.

I had 2 choices here, one was to simply always call the new functions,
but this would break applications that called talloc_free/talloc_steal
against a context that had references. The other was to call the
original functions (renamed to _internal) and live with the bugs in
older apps.

I took the second route because it does not change anything for existing
apps, and, as soon as they are recompiled it will be fixed
automatically, looks like a sane tradeoff to me, but any comment is very
welcome as long as the discussion is polite.

>  > No you can't keep talloc.so.1 and talloc.so.2 at the same time in the
>  > distro, it is too dangerous. Distros will have to wait till next distro
>  > version or rebuild all applications that depend on talloc.
> 
> Can you explain why I have lots of libraries in /usr/lib on my Ubuntu
> system with two version numbers at once? Is everyone else wrong on
> this?

The only libraries I can see with 2 sonames in my Fedora are KDE
libraries, 10 or so, their internal symbols are all auto-generated, and
they are never loaded together in the same app because they are internal
KDE libs nobody directly links them in so there is probably little to no
risk.
I see no other library distributed in 2 soname versions in my F-10.

> In fact, the whole darn point of having so numbers is so you _can_
> have multiple installed at once, and so old apps that linked against
> the old version will still work. 

No, the soname bumps is meant to make your app fail to even start with a
linker error if you don't have the right version.
The fact you can install 2 in parallel is just a consequence, sometimes
useful, sometimes dangerous. In the talloc case I think it is just
dangerous.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Restore-ABI-compatibility-for-talloc.patch
Type: text/x-patch
Size: 9948 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20090702/0d705aba/0001-Restore-ABI-compatibility-for-talloc.bin