[Webkit-unassigned] [Bug 179914] [GTK] Duplicated symbols in libjavascriptcoregtk and libwebkit2gtk can cause crashes in production builds

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=179914

--- Comment #56 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #55)
> I spent a good deal of time last night reading about linkers, and
> unfortunately my main takeaway is that it's time to start learning how ELF
> works.

This is a great article about it, but I haven't had time to read in deep yet.

https://www.akkadia.org/drepper/dsohowto.pdf

> What I fail to understand is: why is that list so small? Are those really
> the only global/static template instantiations of bmalloc and WTF objects
> from the WebCore and WebKit layers? That seems unlikely.

Note that WebCore is not shared, so that's not a problem. This is the list of symbols in the .bss section that are unique global in libjsc and are also present in libwk.

> (In reply to Carlos Garcia Campos from comment #53)
> > I think this is only a problem with static symbols (in bss section) that are
> > unique global in libjsc and local in libwk. Making them unique global in
> > libwk ensures only one will be used. Right?
> 
> I think so. And our linker version script is responsible for making them
> local, which breaks everything.

We have used that script for long time, and this is the first time we have an issue, so break everything sounds a bit exaggerated to me, but still.

> But template instantiations are by default
> unique global or weak, so that duplicate instantiations can be merged
> together by the dynamic linker. (Source:
> http://www.lurklurk.org/linkers/linkers.html#templates, a good article.) So
> I think we can conclude that our linker script is broken, because making
> symbols local does not account for the need to deduplicate global C++
> templates.

Instead of listing symbols, my script could create the version script directly, including in the global section all those symbols to ensure they are unique global. I could run that script as part of make-dist when -c option is given, for example.

> But keep in mind, we have another problem here too: we're not running the
> linker script at all on libjsc. That's why it's not broken in the same way
> as libwk, but the cost is that none of the internal symbols are hidden.

Yes, and this is not easy to fix, because we use a lot of internal symbols of jsc in WebCore and WebKit layers. 

> I
> know we don't have a .pc file for libjsc,

We have a .pc for libjsc.

> so it's maybe not intended to be
> used directly,

It is, currently it's only used by libwebkit, but in the past it as used by seed too.

>  but it is present in the system library path, and we really
> shouldn't be exposing the internals of the library there.

This is not easy to avoid I'm afraid.

> But: it seems impossible to reconcile the desire to hide the internal
> symbols with the desire to install two shared libraries, one of which
> depends on the other but which uses internal symbols of the other.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171213/ef3fe30c/attachment-0001.html>