A change in the way glibc handles memcpy breaks sound in the 64bit flash plugin from Adobe. The sound is distorted and crackles. Apparently this is a bug in the flash player according to https://bugzilla.redhat.com/show_bug.cgi?id=638477 Since you can't patch the flash plugin, maybe you can patch glibc until adobe fixes the problem, which could take months. Linus Torvalds posted a possible patch in the redhat bug. Unfortunately it is not possible or recomended to downgrade glibc. Reproducible: Always Steps to Reproduce:
Actually you _can_ patch the flash plugin. See attachements to the link you gave.
i can confirm this problem. i hope there is a solution soon. :(
Thanks Rodolphe, I didn't see the patch script for the binary flash player. I'll try this out tonight. It would be great if the ebuild for flash could apply this automatically if a 64bit version is installed and glibc is 2.13.
I can confirm the instructions to patch the binary at https://bugzilla.redhat.com/show_bug.cgi?id=638477#c117 fixed it for me. In addition the the steps described there I had to do a chmod 655 /opt/Adobe/flash-player/libflashplayer.so otherwise firefox wouldn't load the plugin. Works fine now.
Thanks for reporting. This is (In reply to comment #4) > I can confirm the instructions to patch the binary at > https://bugzilla.redhat.com/show_bug.cgi?id=638477#c117 fixed it for me. In > addition the the steps described there I had to do a > chmod 655 /opt/Adobe/flash-player/libflashplayer.so > otherwise firefox wouldn't load the plugin. Works fine now. > This works for me, too. Thanks for the reporting.
Didn't work for me, the modified plugin didn't load (no error messages and yes, the permissions were right). Linus workaround from the same Redhat bug worked however, after using an absolute path in LD_PRELOAD: https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38
*** Bug 354395 has been marked as a duplicate of this bug. ***
Unfortunately I don't think we (as in "the ebuild") is legally allowed to patch the flash plugin. We are bound by their license to not mirror or alter their binary. The LD_PRELOAD idea may be the right thing to do, I'll see if I can come up with some way to roll this in to the ebuild... Patches welcome, if anyone out there gets to it before I do.
On the other hand, patching glibc to alias memcpy to memmove may also be a good solution, adding toolchain team for their opinion on this. The Redhat bug in the URL has a bunch of nice explanations from Linus Torvalds on why he thinks patching glibc would be an acceptable workaround, for example: https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129 @toolchain: What do you think - Would you be willing to patch glibc-2.13?
Created attachment 262133 [details, diff] "workaround"
(In reply to comment #8) > Unfortunately I don't think we (as in "the ebuild") is legally allowed to patch > the flash plugin. We are bound by their license to not mirror or alter their > binary. "We're" not, as far as I can tell. The user is altering the binary. (In reply to comment #9) > On the other hand, patching glibc to alias memcpy to memmove may also be a good > solution, adding toolchain team for their opinion on this. While this might work, this really sounds like a terrible idea. glibc made a change which stayed within the spec, and because some poorly written (proprietary) application used the wrong function (Really, this is C 101) we're going to patch glibc? Flash fucking sucks. Please don't do anything of this magnitude to work-around this universally known fact. Since flash blows, I say patching the libflashplayer.so library is the best work-around until they fix their crap.
I'd say that in that Fedora bug, most interesting part is not the https://bugzilla.redhat.com/show_bug.cgi?id=638477#c117 but https://bugzilla.redhat.com/show_bug.cgi?id=638477#c122 especially that some people there claim that flash works with this even better than before and https://bugzilla.redhat.com/show_bug.cgi?id=638477#c170 claims it's usable for 32bits too.
glibc isnt changing. patching the binary isnt a problem like Matt says. just put it behind USE=bindist. same exact situation as binary drivers like nvidia.
I experienced the same problem, would never have guessed it to have something to do with the glibc. I managed to work around the crackles by installing the 32 bit version only on my amd64 multilib system. (e.g. last.fm and youtube work in chromium now flawlessly, prior to this i had crackles on last.fm, but not on youtube) On the other hand in opera there is now no flash available at all. regards, fabian
If I recall, most new bugs that come with glibc-2.13 are related to the new multiarch feature, by which run-time CPU detection is used to have memory and string functions take advantage of new SIMD instructions if possible. Unfortunately some packages (Flash, Skype, etc.) don't work with some of those new functions. So IMO, toolchain may consider adding an IUSE "multiarch" to glibc, so that users can disable the "multiarch" feature. (configure --disable-multiarch) This way, users who have upgraded to 2.13 and wish to use adobe-flash can just rebuild glibc with USE=-multiarch, without having to downgrade.
(In reply to comment #15) > If I recall, most new bugs that come with glibc-2.13 are related to the new > multiarch feature, by which run-time CPU detection is used to have memory > and string functions take advantage of new SIMD instructions if possible. memcpy(3p) explicitly says: "If copying takes place between objects that overlap, the behavior is undefined." So, if an application breaks because it has relied on an undefined implementation detail, then it seems very clear to me that it's _not_ glibc that is to blame for it.
(In reply to comment #16) > memcpy(3p) explicitly says: "If copying takes place between objects that > overlap, the behavior is undefined." So, if an application breaks because it > has relied on an undefined implementation detail, then it seems very clear to > me that it's _not_ glibc that is to blame for it. I was not blaming glibc. Sure it is Adobe that should fix the bug. I was simply giving a possible workaround for this problem. After all, glibc has been providing "--enable-multi-arch" and "--disable-multi-arch" for some time. Even without these bugs it doesn't seem to be a bad idea to add an USE for it.
(In reply to comment #11) > (In reply to comment #8) > > Unfortunately I don't think we (as in "the ebuild") is legally allowed to patch > > the flash plugin. We are bound by their license to not mirror or alter their > > binary. > > "We're" not, as far as I can tell. The user is altering the binary. A good point, that. I suppose we're not *distributing* an altered binary. Okay, so I've set up a new ebuild to patch the 64bit version, please give it a try and report back here with success/failure. www-plugins/adobe-flash-10.2.152.27_p201011173-r2
at least here: Portage 2.1.9.39 (default/linux/amd64/10.0, gcc-4.4.5, glibc-2.13-r0, 2.6.38-rc4 x86_64) www-plugins/adobe-flash-10.2.152.27_p201011173-r2 fixed the sound problem with flash videos without having to use the LD_PRELOAD workaround. Great job :-) Let's hope adobe will fix this in their next version...
adobe-flash-10.2.152.27_p201011173-r2 doesn't set RESTRICT="bindist" as comment 13 suggested. The redistribution of modified versions is not permitted by the license.
(In reply to comment #18) > Okay, so I've set up a new ebuild to patch the 64bit version, please give it a > try and report back here with success/failure. thank you for the fix :)
memcpy-to-memmove.sh doesn't work with /bin/sh -> dash, it fails with >>> Compiling source in /var/tmp/portage/www-plugins/adobe-flash-10.2.152.27_p201011173-r2/work ... trap: 20: ERR: bad trap It's easily fixed by changing line 130 of the ebuild from sh "${FILESDIR}/memcpy-to-memmove.sh" libflashplayer.so \ to bash "${FILESDIR}/memcpy-to-memmove.sh" libflashplayer.so \ However, since I don't use glibc-2.13, I can only say that the Flash plugin seems to run as before.
(In reply to comment #22) > bash "${FILESDIR}/memcpy-to-memmove.sh" libflashplayer.so bash is also needed here for other reasons: The script contains several bashisms (e.g. echo -n and near the end an echo -ne which will badly break without errors with dash).
(In reply to comment #22) > bash "${FILESDIR}/memcpy-to-memmove.sh" libflashplayer.so \ Good catch, thanks :) Fixed in -r2
*** Bug 355599 has been marked as a duplicate of this bug. ***
No complaints since my -r2 bump, considering this fixed.
