Ticket #501 (closed task: fixed)

Opened 4 years ago

Last modified 4 years ago

Fixing the glibc adobe flash incompatibility

Reported by: jwrdegoede Owned by:
Priority: major Keywords: meeting
Cc: robatino, lmacken, michich, gholms Blocked By:


Proposal topic

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>



Change History

comment:1 Changed 4 years ago by robatino

  • Cc robatino added

comment:2 Changed 4 years ago by lmacken

  • Cc lmacken added

comment:3 Changed 4 years ago by michich

  • Cc michich added

comment:4 Changed 4 years ago by gholms

  • Cc gholms added

comment:5 Changed 4 years ago by kkofler

A recent glibc update has broken the adobe flash plugin and the glibc maintainers are refusing to fix this.

And they're right:

  • This is a bug in Flash. glibc is entirely the wrong place to fix it.
  • This is a bug in proprietary software. We do not support proprietary software.
  • Adding such workarounds can hurt Free Software users by degrading performance.
  • Adding such workarounds removes the incentive for Adobe to fix their code.
  • Adding such workarounds removes the incentive for considering Free alternatives to Flash.

We should not work around Adobe's bugs. Any complaints about the breakage should be sent to Adobe.

comment:6 Changed 4 years ago by rathann

However, it would be nice if glibc warned about overlapping memcpy since it's clearly used in applications instead of silently breaking them. That has also been suggested in the bug. Clearly it's technically correct to shrug this off as "not our problem", but IMHO reverting memcpy change and adding a warning for, say, one Fedora release wouldn't hurt anyone, but give us the opportunity to say: "See, we've been warning you for 6 months. Don't cry now." Instead of the current uproar.

comment:7 Changed 4 years ago by kkofler

The problem is that range checking all memcpy operations wastes a lot of CPU cycles. For short memcpy operations, it can even take longer than doing the copy in the first place!

comment:8 Changed 4 years ago by tuxbrewr

as mentioned the glibc maintainers are correct it is not a bug in glibc. However being right does not solve the problem from the users point of view. The correct answer in the case is to revert the change in glibc until such time as Adobe issues a fix or another work around is found.

We might not all like the use of proprietary software, but it is a fact of life that it is out there and our users want to use it,so we have to support it.

comment:9 Changed 4 years ago by kkofler

Fedora has never supported proprietary software, why should we now suddenly "have to support it"?

Those users out there can use one of several workarounds which do not require modifying Fedora packages for that third-party bug:

  • Just use the 32-bit version. (FYI, that's still the only one considered stable by Adobe and offered through Adobe's YUM repository.) That's what nspluginwrapper is for.
  • LD_PRELOAD another implementation of memcpy, such as the Linus one (as posted to the bug report).
  • Use that script (also posted to the bug report) which patches the binary to use memmove instead of memcpy everywhere.

It's really not the job of our glibc (or nspluginwrapper, xulrunner etc.) maintainers to work around this bug in their non-buggy packages!

comment:10 Changed 4 years ago by kevin

  • Keywords meeting added

I meant to add this to the agenda for the meeting today, but it slipped through the cracks. ;( Sorry about that.

comment:11 Changed 4 years ago by kevin

  • Status changed from new to closed
  • Resolution set to fixed

I've reopened the bug and asked the glibc maintainers to reconsider based on the technical arguments.

We are not going to force them to revert this however. It's up to people to provide good technical arguments that convince them.

Note: See TracTickets for help on using tickets.