Ticket #501 (closed task: fixed)
Fixing the glibc adobe flash incompatibility
|Reported by:||jwrdegoede||Owned by:|
|Cc:||robatino, lmacken, michich, gholms||Blocked By:|
A recent glibc update has broken the adobe flash plugin and the glibc maintainers are refusing to fix this.
A recent glibc update has broken the adobe flash plugin and the glibc maintainers are refusing to fix this. I'm about to start a discussion about this on fedora-devel and I would like FESCo to look into this during one of our next meetings. I believe this makes us look bad, and the glibc maintainers do not look like they are going to do anything about this without intervention.
Here is a copy of the mail I'm about to send to fedora-devel:
For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin.
The problem has been analyzed and is known, as well as a fix for it, see: https://bugzilla.redhat.com/show_bug.cgi?id=638477
The problem still exists however. The glibc developers say that this is not a glibc bug, but a flash plugin bug. And technically they are 100% correct, and the adobe flash plugin is a buggy .... (no surprise there). To be specific the flash plugin is doing overlapping memcpy-s which is clearly not how memcpy is supposed to be used. But the way the flash plugin does overlapping memcpy's happens to work fine as long as one as the c library does the memcpy-s in forward direction. And the new memcpy implementation does the memcpy in backward direction.
The glibc developers being technically 100% correct is not helping our end users in this case though. So we (The Fedora project) need to come up with a solution to help our end users, many of whom want to use the adobe flash plugin.
This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring any further user intervention.
I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov.
I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: <url to fesco ticket>