[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 #55 from Michael Catanzaro <mcatanzaro at igalia.com> ---
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.

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.

(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. 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.

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. I know we don't have a .pc file for libjsc, so it's maybe not intended to be used directly, but it is present in the system library path, and we really shouldn't be exposing the internals of the library there.

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/0aa47a77/attachment.html>