[Natty] Strange beeping sound when viewing flash video

[Id2ndR]

Binary package hint: adobe-flashplugin

As describe in the thread http://ubuntuforums.org/showthread.php?t=1692707 the sound is bad in natty.

Workaround: patch the flash plugin to change memcpy call to memmove
- Download https://bugzilla.redhat.com/attachment.cgi?id=460254
- Run this script: $ sudo bash ./fix-flash.sh /usr/lib/flashplugin-installer/libflashplayer.so
- Restart the browser

[jc1da.3011 (jc1da.3011-redhat-bugs)]

Description of problem:
Strange sound when playing mp3 on website using flash (using Shockwave Flash 10.2 d161).
Tested and work fine on Youtube ( no strange sound )

[JC1DA@jc1da-laptop ~]$ dmesg | grep realtek
ALSA sound/pci/hda/patch_realtek.c:1358: realtek: No valid SSID, checking pincfg 0x411111f0 for NID 0x1d
ALSA sound/pci/hda/patch_realtek.c:1441: realtek: Enable default setup for auto mode as fallback

Version-Release number of selected component (if applicable):

How reproducible:
terrible sound on this site
http://mp3.zing.vn/mp3/nghe-bai-hat/Tennessee-Line-Daughtry.IW6WUFWE.html

Steps to Reproduce:
1.
2.
3.

Actual results:
terrible sound

Expected results:
good as on Fedora 13

Additional info:

[rhbugs (rhbugs-redhat-bugs)]

Try as I might, I cannot see how this report is related to the soundtracker package. Could you elaborate on that?

[jc1da.3011 (jc1da.3011-redhat-bugs)]

sorry wrong Component

[notting (notting-redhat-bugs)]

*** Bug 638678 has been marked as a duplicate of this bug. ***

[notting (notting-redhat-bugs)]

Have you confirmed that F13 works the same *with the same version of flash*?

[jc1da.3011 (jc1da.3011-redhat-bugs)]

No, F13 works fine with Shockwave Flash 10.2 d161

[jc1da.3011 (jc1da.3011-redhat-bugs)]

One more things, I used RhythmBox to play mp3, flac files, it works fine ... no strange sound like on some flash websites(exclude youtube)

[m.a.young (m.a.young-redhat-bugs)]

I am hearing similar symptoms with a different sound card (64-bit flash preview gives jumpy sound for some sites in F14, but the same flash works in F13).
lspci -vs 00:1b.0 gives
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
 Subsystem: Dell Device 022f
 Flags: bus master, fast devsel, latency 0, IRQ 47
 Memory at fe9fc000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: [50] Power Management version 2
 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
 Capabilities: [100] Virtual Channel
 Capabilities: [130] Root Complex Link
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel

[torvalds (torvalds-redhat-bugs)]

I see this as well. Sounds like clipping or some really bad sample rate frequency conversion. I also use the preview 64-bit adobe flash, and it doesn't happen for everything (not local mp3 players, for example).

It doesn't seem to happen with most (all?) youtube videos, but happens commonly with other sources. The example given in comment #1 is a good example, and breaks for me too. If I had to guess, I'd think some flash audio is using a different sample rate (or bits per sample), and the conversion is buggered.

F13 worked with the same flash binary.

And yes, I'm using Intel HDA too. Probably not related, though.

00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)

[mhasko (mhasko-redhat-bugs)]

Happens to me as well
Also in youtube 240p quality, not in higher, so I think might be the "bad sample rate frequency conversion" as in comment #8.

Flash 64bit version 10.2 d161

$ lspci -vs 1b
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
 Subsystem: Lenovo Device 20f2
 Flags: bus master, fast devsel, latency 0, IRQ 50
 Memory at fc020000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: <access denied>
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel

[notting (notting-redhat-bugs)]

Turning off power_save in snd-hda-intel seems to fix this in a quick test for me. Not sure what's causing it to be an issue in this combination.

[notting (notting-redhat-bugs)]

... perhaps not. It fixed it until the next stream opened.

[notting (notting-redhat-bugs)]

That being said, if I remove pulseaudio, where flash accesses the sound device directly, the audio still stutters. Assigning to the kernel for the driver.

[m.a.young (m.a.young-redhat-bugs)]

There is a problem with the kernel driver theory. If I boot an F14 install with an F12 based kernel then I still get the broken sound.

[torvalds (torvalds-redhat-bugs)]

(In reply to comment #13)
> There is a problem with the kernel driver theory. If I boot an F14 install with
> an F12 based kernel then I still get the broken sound.

Also, I did a "yum upgrade" from F13 to F14, and since I (obviously) always compile my own kernels, I can say that both the kernel and the libfrashplayer.so binary stayed constant over the upgrade - yet the problem did not exist in F13.

So while it may be somehow tied to the kernel or to libflashplayer, it is definitely something in Fedora-14 that triggers the problem.

On a suggestion from Takashi Iwai I tried to "downgrade" alsa-lib to the F13 version (I say "downgrade", because the version number seems to be the same in F13 and F14), and that didn't make any difference.

So it isn't the kernel, it's not libflashplayer.so, and it doesn't seem to be alsa-lib. If it's not pulseaudio, then what else is involved in sound generation?

[m.a.young (m.a.young-redhat-bugs)]

The trigger of the problem is the glibc version. If I start with F13 (sounds works) and then upgrade to the F14 glibc and nscd packages the sound starts breaking up. If I downgrade to F13 glibc again the sound works again. However it isn't obvious to me why that should make a difference.

[m.a.young (m.a.young-redhat-bugs)]

The reverse is also true. The sound is good with F13 glibc (2.12.1-4) on F14. I have been hunting through glibc versions. The sound was good with glibc-2.12.90-3 but first started sounding corrupted with glibc-2.12.90-4.

[schwab (schwab-redhat-bugs)]

valgrind?

[m.a.young (m.a.young-redhat-bugs)]

Created attachment 457145
Valgrind output

This is with seamonkey running the 64-bit flash plugin preview.

[schwab (schwab-redhat-bugs)]

I see no valgrind of flash player.

[m.a.young (m.a.young-redhat-bugs)]

What options would you suggest to capture it? I was running valgrind --trace-children=yes --leak-check=full -v seamonkey

[schwab (schwab-redhat-bugs)]

Please trace the process that creates the sound.

[m.a.young (m.a.young-redhat-bugs)]

Created attachment 457151
Valgrind output

seamonkey is the process that produces the sound, via the flash plugin. I am attaching a second valgrind trace, removing nspluginwrapper from the process in case that improves the trace.

Actually the sound is better when seamonkey is run under valgrind, so it is possible that the hooks valgrind puts in to do its monitoring is bypassing the problem.

[schwab (schwab-redhat-bugs)]

Please check that there are no calls to memcpy with overlapping regions.

[m.a.young (m.a.young-redhat-bugs)]

How can I do that?

[drewskiwooskie (drewskiwooskie-redhat-bugs)]

I am also getting the issue, but only with the 64bit version of flash (either the square release or latest stable). If I use the 32bit and wrap it as per http://fedoraproject.org/wiki/Flash , either version of square or release works perfectly. Seems it happens just with the 64bit flash plugin.

I am also on hda-intel but not sure if that matters at all.
lspci -vs 1b
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
 Subsystem: Dell Device 0233
 Flags: bus master, fast devsel, latency 0, IRQ 49
 Memory at f6adc000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: <access denied>
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel

[rubberglove (rubberglove-redhat-bugs)]

I can also confirm (as in comment 25) that I only get this issue with the 64-bit version of the plugin, but using the 32-bit wrapped plugin works fine.

I also (like everyone?) have an intel card:

lspci -vs 1b
00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller
 Subsystem: ASUSTeK Computer Inc. Device 82fe
 Flags: bus master, fast devsel, latency 0, IRQ 45
 Memory at fe3f4000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: <access denied>
 Kernel driver in use: HDA Intel
 Kernel modules: snd-hda-intel

[jc1da.3011 (jc1da.3011-redhat-bugs)]

I confirm that it works fine with the 64 bit version of flash ... 32 bit wrapped plugins just fine ...

[swantz051 (swantz051-redhat-bugs)]

I can confirm as well. Using a Creative card.

lspci -vs 03.0
04:03.0 Multimedia audio controller: Creative Labs CA0106 Soundblaster
 Subsystem: Creative Labs SB0570 [SB Audigy SE]
 Flags: bus master, medium devsel, latency 64, IRQ 19
 I/O ports at cca0 [size=32]
 Capabilities: <access denied>
 Kernel driver in use: CA0106
 Kernel modules: snd-ca0106

[sitsofe (sitsofe-redhat-bugs-1)]

Just adding another me too (on Fedora 14). Temporarily turning off selinux and doing

LD_PRELOAD="/dev/shm/glibc-2.12.1-4/lib64/libc.so.6 /dev/shm/glibc-2.12.1-4/lib64/libpthread.so.0" chromium-browser --app=http://news.bbc.co.uk/1/hi/entertainment/8266142.stm

didn't produce the distorted sound (I used chromium so that the LD_PRELOAD environment variable would actually be passed to the flash plugin). Looking at the changelog for glibc-2.12.90-4 shows:

* Fri Jul 02 2010 Andreas Schwab <email address hidden> - 2.12.90-4
- Update from master
  - Work around kernel rejecting valid absolute timestamps
  - Improve 64bit memcpy/memmove for Atom, Core 2 and Core i7
  - Fix error handling in Linux getlogin*
- Workaround assembler bug sneaking in nopl (#579838)
- Fix scope handling during dl_close
- Fix setxid race handling exiting threads

It would be interesting to know if this is happening on AMD 64 bit machine. It is interesting that previous comments suggest the 32 bit flash does not seem to be demonstrating this problem.

I used chromium to run valgrind on the flash plugin ( chromium-browser --plugin-launcher="valgrind" --app=http://news.bbc.co.uk/1/hi/entertainment/8266142.stm --no-sandbox ). Large amounts of
"Conditional jump or move depends on uninitialised value(s)"
went past but just before it started outputting sound the following came up:

==2100== Conditional jump or move depends on uninitialised value(s)
==2100== at 0x1B2E9361: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF89F92: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF8A784: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF8F8CA: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF916E0: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF5FF4A: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF61ABD: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF61AD2: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF18AC7: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF18BE4: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF80D43: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AE7126A: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100==
==2100== Thread 9:
==2100== Source and destination overlap in memcpy(0x256d7170, 0x256d7570, 1280)
==2100== at 0x4A06A3A: memcpy (mc_replace_strmem.c:497)
==2100== by 0x1B122B87: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1B1230DF: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1B1232C5: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF491F0: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1AF4AFDA: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1B06DA69: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1B06EA23: ??? (in /usr/lib64/mozilla/plugins/libflashplayer.so)
==2100== by 0x1EF26D88: write_data (flashsupport.c:872)
==2...

[sitsofe (sitsofe-redhat-bugs-1)]

(I forgot to say, the machine I'm using is an Intel Core 2 laptop with an Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02))

[torvalds (torvalds-redhat-bugs)]

(In reply to comment #29)
> Looking at the changelog for glibc-2.12.90-4 shows:
>
> * Fri Jul 02 2010 Andreas Schwab <email address hidden> - 2.12.90-4
> [...]
> - Improve 64bit memcpy/memmove for Atom, Core 2 and Core i7
> [...]
> I used chromium to run valgrind on the flash plugin [...]
> ==2100== Thread 9:
> ==2100== Source and destination overlap in memcpy(0x256d7170, 0x256d7570, 1280)
> ==2100== at 0x4A06A3A: memcpy (mc_replace_strmem.c:497)

That does look like a very possible smoking gun.

Normally, a memcpy that copies _downwards_ (like the one above) will work
perfectly well in practice, because the "natural" way to do memcpy() by making
it just copy things upwards will "just work" even for the overlapping case.

So it would be a bug to use memcpy for overlapping areas, but it would be a
bug that normally would never show up.

But if the new improved 64bit memcpy started copying things backwards, it might
cause trouble with such an overlapping memcpy user.

[ That said - why the heck would you ever do memcpy() backwards? Things like
  automatic prefetchers usually work better for the "natural" patterns, so a
  backwards memcpy is generally a bad thing to do unless you have some active
  reason for it, like doing a memmove() ]

> On a related note, is there a glibc environment flag that can be set to force a
> generic memcpy routine to run?

Indeed, that would be very interesting to see.

Andreas?

[sitsofe (sitsofe-redhat-bugs-1)]

Linus is right - looking at the memcpy patch comments ( http://article.gmane.org/gmane.comp.lib.glibc.alpha/1527 ) shows it is going backwards. One of the CPU feature tests that must pass before this memcpy is used is called HAS_FAST_COPY_BACKWARD.

[sitsofe (sitsofe-redhat-bugs-1)]

Sorry, the link should have been http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278 .

[schwab (schwab-redhat-bugs)]

Tell adobe.

[belegdol (belegdol-redhat-bugs)]

https://bugs.adobe.com/jira/browse/FP-5739

[belegdol (belegdol-redhat-bugs)]

If someone knows how to make Adobe pay more attention than usual, this would be perfect.

[m.a.young (m.a.young-redhat-bugs)]

I did notice a forum post http://forums.adobe.com/thread/748698?tstart=0 which it might be worth adding a comment to if you have a suitable account to do so. It might also be explicitly pointing to the memcpy man page which says it shouldn't be used for overlapping regions so that Adobe realize they are doing something broken which just happened to work previously.

MEMCPY(3) Linux Programmer's Manual MEMCPY(3)

NAME
       memcpy - copy memory area

SYNOPSIS
       #include <string.h>

       void *memcpy(void *dest, const void *src, size_t n);

DESCRIPTION
       The memcpy() function copies n bytes from memory area src to memory
       area dest. The memory areas should not overlap. Use memmove(3) if the
       memory areas do overlap.

....

[torvalds (torvalds-redhat-bugs)]

So in the kernel we have a pretty strict "no regressions" rule, and that if people depend on interfaces we exported having side effects that weren't intentional, we try to fix things so that they still work unless there is a major reason not to.

So I'm disappointed glibc just closes this as NOTABUG. There's no real reason to do the copy backwards that I can see, so doing it that way is just stupid.

But whatever. You can do a LD_PRELOAD trick to get a sane memcpy(), and it does indeed fix the sound for me. Just do something like this:

    prompt$ cat > mymemcpy.c
    #include <sys/types.h>

    void *memcpy(void *dst, const void *src, size_t size)
    {
 void *orig = dst;
 asm volatile("rep ; movsq"
  :"=D" (dst), "=S" (src)
  :"0" (dst), "1" (src), "c" (size >> 3)
  :"memory");
 asm volatile("rep ; movsb"
  :"=D" (dst), "=S" (src)
  :"0" (dst), "1" (src), "c" (size & 7)
  :"memory");
 return orig;
    }
    ^D
    prompt$ gcc -O2 -c mymemcpy.c
    prompt$ ld -G mymemcpy.o -o mymemcpy.so
    prompt$ LD_PRELOAD mymemcpy.so /opt/google/chrome/google-chrome &

and it does seem to work. Not a lot of testing, but at least TED-talks work for me again (and I tested the Daughtry thing too, although I am not convinced it sounds all that much better without the sound corruption).

[schwab (schwab-redhat-bugs)]

The only stupidity is crap software violating well known rules that have existed forever.

[torvalds (torvalds-redhat-bugs)]

(In reply to comment #39)
> The only stupidity is crap software violating well known rules that have
> existed forever.

Umm. Bugs happen. That's a fact.

You can call it "crap software" all you like, but the thing is, if memcpy doesn't warn about overlaps, there's no test coverage, and in that case even well-designed software will have bugs.

Then the question becomes one of "Why break it?"

I have yet to hear the actual _reason_ for making the change to memcpy. We know what the downside is. What's the upside?

[schwab (schwab-redhat-bugs)]

See comment 29. This is well known.

[torvalds (torvalds-redhat-bugs)]

Andreas - I know it's a well-known issue. That doesn't change anything at all. Read my comment: bugs happen.

What's the upside of breaking things? That's all I'm asking for.

[jakub (jakub-redhat-bugs-1)]

The upside is (ought to be) faster memcpy, which is something that helps a lot of apps. Recent glibcs use STT_GNU_IFUNC magic to select one out of several different versions of many of the common string/memory ops as well as a few other functions, depending on what CPU is used.

[sitsofe (sitsofe-redhat-bugs-1)]

Jakub:
Is there a way to force the function STT_GNU_IFUNC runs for glibc to select a different version based on an environment variable (I searched the web a few days ago but turned up nothing)?

[jakub (jakub-redhat-bugs-1)]

No (except for LD_PRELOAD).
The thing is, the IFUNC decision function can be only very limited, it is called during relocation processing, so it can't rely too much on relocation processing having been performed already. And it must be very fast and thread-safe, doing getenv there would be very problematic. It usually just either tests cpuid flags or tests saved cpuid flags and vars computed from that.
Plus, each of the function usually has a different set of decisions, there is no common notion of oldest etc.

[torvalds (torvalds-redhat-bugs)]

(In reply to comment #43)
> The upside is (ought to be) faster memcpy, which is something that helps a lot
> of apps.

Hey, I'm a big believer in fast memcpy's, I just don't believe that going
backwards helps performance.

In the kernel, the optimized x86 memcpy we use is actually a memmove(), because while performance is really important, so is repeatability and avoiding surprises (strictly speaking, we have two: the "rep movs" version for the case where that is supposed to be fast, and the open-coded copy version. The "rep movs" version is forwards-only and doesn't handle overlapping areas).

I dunno. I just tested my stupid "mymemcpy.so" against the glibc memcpy() on the particular kind of memcpy that valgrid reports (16-byte aligned 1280-byte memcpy).

I did both cached (same block over and over) and non-cached (a million blocks in sequence).

For the cached case my stupid LD_PRELOAD version was consistently a bit faster.

The noise on the non-cached case was larger, but the glibc memcpy may have been faster. I say "may have been" because it went both ways: I did ten runs, and my LD_PRELOAD one still won 6 out of those 10 runs, but the noise was large enough that I will allow that I'm not going to guarantee anything.

Do I have a point? I bothered to _measure_ the speed, and according to my measurements, glibc wasn't any faster than my trivial version and was likely slower. But I only tested two cases.

Regardless, it boils down to: we know the glibc change resulted in problems for real users. We do _not_ know that it helped anything at all.

And in the end, the big question is simple:

Are you seriously going to do a Fedora-14 release with a known non-working flash player?

[horsley1953 (horsley1953-redhat-bugs)]

Then, of course, there is the wacked out side effects STT_GNU_IFUNC has
when you are running a process in a virtual machine and try to live migrate
it to a slightly different architecture host :-). Glibc is trying to be
too clever for anyone's good.

[torvalds (torvalds-redhat-bugs)]

(In reply to comment #47)

I doubt that is much of a problem in practice, since it's presumably done once at process startup, so live migration at worst just means that you might have the slightly differently optimized version running.

And if you depend on actual semantic issues (ie "does this machine support SSE4"), then that just means that you'd better live migrate between machines that are sufficiently similar for that to all work.

So no, I don't think live migration is likely to be a big issue. Not compared to "flash doesn't work right".

[mglantz (mglantz-redhat-bugs)]

(In reply to comment #38)
> prompt$ gcc -O2 -c mymemcpy.c
> prompt$ ld -G mymemcpy.o -o mymemcpy.so
> prompt$ LD_PRELOAD mymemcpy.so /opt/google/chrome/google-chrome &

For anyone that is having issues following this, change
prompt$ LD_PRELOAD mymemcpy.so /opt/google/chrome/google-chrome &
to
prompt$ LD_PRELOAD=mymemcpy.so /opt/google/chrome/google-chrome &

A note:
I myself did have issues using this fix, I got 6 instances of this error message:
ERROR: ld.so: object 'mymemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.

[mglantz (mglantz-redhat-bugs)]

(In reply to comment #49)
I had no issues compiling it, no real clues (for me, a non-programmer).
Running 2.6.35.6-48.fc14.x86_64, glibc-2.12.90-18

[teva.riou (teva.riou-redhat-bugs)]

Try something like this:
LD_PRELOAD=/full/path/to/mymemcpy.so /opt/google/chrome/google-chrome &

or for firefox:
LD_PRELOAD=/full/path/to/mymemcpy.so /usr/bin/firefox &

[torvalds (torvalds-redhat-bugs)]

(In reply to comment #49)
>
> I myself did have issues using this fix, I got 6 instances of this error
> message:
> ERROR: ld.so: object 'mymemcpy.so' from LD_PRELOAD cannot be preloaded:
> ignored.

Try giving it the whole absolute pathname.

I should really have cut-and-pasted my actual command lines rather than try to
write them out and getting them wrong. My actual command line was really

  LD_PRELOAD=/home/torvalds/mymemcpy.so /opt/google/chrome/google-chrome &

but you'd obviously have to fix that "/home/torvalds" part to match where-ever
you end up installing that .so file.

The nicest alternative might be to just install that mymemcpy.so into the
google chrome directory, and add the LD_PRELOAD to the wrapper shell script
that google chrome already uses for the xdg binaries and the ffmpeg library.

And obviously something similar should work for firefox. I just happen to use
chrome, so I gave the directions (approximate as they were) for the thing I
tried.

No guarantees. It was a really quick hack.

[mglantz (mglantz-redhat-bugs)]

(In reply to comment #52)
> Try giving it the whole absolute pathname.
That was it :-) Works great for me. Thanks Linus!

So, here's how to bypass the bug (without downgrading glibc), using Google Chrome.

Follow the instructions in comment #38 except for the last intruction, replace:
prompt$ LD_PRELOAD mymemcpy.so /opt/google/chrome/google-chrome &
with
prompt$ LD_PRELOAD=$(pwd)/mymemcpy.so /opt/google/chrome/google-chrome &

[mglantz (mglantz-redhat-bugs)]

Verified that this fix works for Firefox as well.

Just replace
LD_PRELOAD=$(pwd)/mymemcpy.so /opt/google/chrome/google-chrome &
with
LD_PRELOAD=$(pwd)/mymemcpy.so /usr/bin/firefox &

(Make sure you've shutdown all running copies of firefox before doing this)

[mglantz (mglantz-redhat-bugs)]

I'm sure thousands of people will find their way here, so, here's a quicky. To bypass this issue (which is an issue in Adobe Flash), you may run the below "fix" brought forth in comment #38

1. Cut and paste this into a prompt:
---Cut below---
cat > $HOME/Downloads/linusmemcpy.c <<EOF
#include <sys/types.h>

void *memcpy(void *dst, const void *src, size_t size)
{
void *orig = dst;
asm volatile("rep ; movsq"
:"=D" (dst), "=S" (src)
:"0" (dst), "1" (src), "c" (size >> 3)
:"memory");
asm volatile("rep ; movsb"
:"=D" (dst), "=S" (src)
:"0" (dst), "1" (src), "c" (size & 7)
:"memory");
return orig;
}
EOF
cd $HOME/Downloads
gcc -O2 -c linusmemcpy.c
ld -G linusmemcpy.o -o linusmemcpy.so
---Stop cutting here---

2. Shutdown any running copies of your webbrowser.

3. Until a Adobe has fixed their Flash player, start your webbrowser as below:

For Firefox users:
LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /usr/bin/firefox &

For Google Chrome users:
LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /opt/google/chrome/google-chrome &

[rh_bugzilla (rhbugzilla-redhat-bugs-1)]

(In reply to comment #38)

Thank you for this neat workaround. Flash is now as happy as can be expected. In spite of the NOTABUG, hopefully the glibc developers or Fedora will come up with a more permanent solution because if we have to wait for Adobe to fix flash, hell in several dimensions will have frozen over multiple times.

[drewskiwooskie (drewskiwooskie-redhat-bugs)]

Bypass fixed my problem as well, thanks!

[n.underwood78 (n.underwood78-redhat-bugs)]

For Firefox users:
LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /usr/bin/firefox &

For Google Chrome users:
LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /opt/google/chrome/google-chrome &

and for opera users?

[teva.riou (teva.riou-redhat-bugs)]

LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /usr/bin/opera &

[pigetak178 (pigetak178-redhat-bugs)]

LD_PRELOAD works for me an FF. Thanks, Linus.

Tag.

[n.underwood78 (n.underwood78-redhat-bugs)]

This fix does not work for me.

[1037][neil@neil-laptop:~/Downloads]$ ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.

[notting (notting-redhat-bugs)]

If you're running with SELinux, you'd need to set the file context on the shared object correctly.

chcon --reference=/lib64/libc.so.6 <your file>

[n.underwood78 (n.underwood78-redhat-bugs)]

This still does not work for me after:

chcon --reference=/lib64/libc.so.6 <your file>

What exactly is this code doing?

[teva.riou (teva.riou-redhat-bugs)]

(In reply to comment #61)
> This fix does not work for me.
>
>
> [1037][neil@neil-laptop:~/Downloads]$ ERROR: ld.so: object
> '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded:
> ignored.
> ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> cannot be preloaded: ignored.
> ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> cannot be preloaded: ignored.
> ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> cannot be preloaded: ignored.
> ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> cannot be preloaded: ignored.

Make sure linusmemcpy.so is in /home/neil/Downloads, otherwise copy it there or type the right path.

LD_PRELOAD=/full/path/to/linusmymemcpy.so /usr/bin/opera &

[n.underwood78 (n.underwood78-redhat-bugs)]

(In reply to comment #64)
> (In reply to comment #61)
> > This fix does not work for me.
> >
> >
> > [1037][neil@neil-laptop:~/Downloads]$ ERROR: ld.so: object
> > '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded:
> > ignored.
> > ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> > cannot be preloaded: ignored.
> > ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> > cannot be preloaded: ignored.
> > ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> > cannot be preloaded: ignored.
> > ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> > cannot be preloaded: ignored.
>
> Make sure linusmemcpy.so is in /home/neil/Downloads, otherwise copy it there or
> type the right path.
>
> LD_PRELOAD=/full/path/to/linusmymemcpy.so /usr/bin/opera &

Everything is where it should be:

[1102][neil@neil-laptop:~/Downloads]$ locate linusmemcpy.so
/home/neil/Downloads/linusmemcpy.so
[1102][neil@neil-laptop:~/Downloads]$ chcon --reference=/lib64/libc.so.6 /home/neil/Downloads/linusmemcpy.so
[1102][neil@neil-laptop:~/Downloads]$ LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /usr/bin/opera &
[2] 14013
[1] Done LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /usr/bin/opera
[1103][neil@neil-laptop:~/Downloads]$ ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.

Sorry to be a pain. My system doesn't seem like this. This does work great for Firefox though. It's just Opera.

[notting (notting-redhat-bugs)]

(In reply to comment #63)
> This still does not work for me after:
>
> chcon --reference=/lib64/libc.so.6 <your file>

Just to be clear, replace '<your file>' with the path to your shared object (in your case /home/neil/Downloads/linusmemcpy.so ... change as necessary.)

> What exactly is this code doing?

Setting the SELinux context so that it's treated as a shared object with code as opposed to just a normal file.

[n.underwood78 (n.underwood78-redhat-bugs)]

(In reply to comment #64)
> (In reply to comment #61)
> > This fix does not work for me.
> >
> >
> > [1037][neil@neil-laptop:~/Downloads]$ ERROR: ld.so: object
> > '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded:
> > ignored.
> > ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> > cannot be preloaded: ignored.
> > ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> > cannot be preloaded: ignored.
> > ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> > cannot be preloaded: ignored.
> > ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD
> > cannot be preloaded: ignored.
>
> Make sure linusmemcpy.so is in /home/neil/Downloads, otherwise copy it there or
> type the right path.
>
> LD_PRELOAD=/full/path/to/linusmymemcpy.so /usr/bin/opera &

Everything is where it should be:

[1102][neil@neil-laptop:~/Downloads]$ locate linusmemcpy.so
/home/neil/Downloads/linusmemcpy.so
[1102][neil@neil-laptop:~/Downloads]$ chcon --reference=/lib64/libc.so.6 /home/neil/Downloads/linusmemcpy.so
[1102][neil@neil-laptop:~/Downloads]$ LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /usr/bin/opera &
[2] 14013
[1] Done LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /usr/bin/opera
[1103][neil@neil-laptop:~/Downloads]$ ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object '/home/neil/Downloads/linusmemcpy.so' from LD_PRELOAD cannot be preloaded: ignored.

Sorry to be a pain. My system doesn't seem like this. This does work great for Firefox though. It's just Opera.

[n.underwood78 (n.underwood78-redhat-bugs)]

AAArrrrggg. Sorry about the double post. To be perfectly clear on my end, this is the exact command I am issuing:

chcon --reference=/lib64/libc.so.6 ~/Downloads/linusmemcpy.c

the exact location of linusmemcpy.c is /home/neil/Downloads

and the exact command to launch Opera:

LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /usr/bin/opera &

And by "What exactly is this code doing?" I was referring to the contents of linusmemcpy.c. I understand the SELinux issue.

[sitsofe (sitsofe-redhat-bugs-1)]

Neil:
file `which opera`

If it's a script which plays with LD_LIBRARY_PATH this may be why you are struggling to get it working.

[n.underwood78 (n.underwood78-redhat-bugs)]

(In reply to comment #69)
> Neil:
> file `which opera`
>
> If it's a script which plays with LD_LIBRARY_PATH this may be why you are
> struggling to get it working.

[1843][neil@neil-laptop:~]$ file `which opera`
/usr/bin/opera: POSIX shell script text executable

The contents of said "POSIX shell script" are:

#!/bin/sh
export OPERA_DIR=${OPERA_DIR:-/usr/share/opera}
exec /usr/lib/opera/opera "$@"

This is just a shell script that points to "/usr/lib/opera/opera"? I'm not quite sure I get the reason behind this.

I appreciate all the assistance. I'll just have to wait for the official update. If I really can't handle the sound I'll just use FF for the time being.

*sigh*...why does Opera always have to be so damn difficult?...

[joolli (joolli-redhat-bugs)]

Add:

export LD_PRELOAD=$HOME/Downloads/linusmemcpy.so

to the Opera shell script so it looks like:

#!/bin/sh
export OPERA_DIR=${OPERA_DIR:-/usr/share/opera}
export LD_PRELOAD=$HOME/Downloads/linusmemcpy.so
exec /usr/lib/opera/opera "$@"

That should do the trick.

[n.underwood78 (n.underwood78-redhat-bugs)]

(In reply to comment #71)
> Add:
>
> export LD_PRELOAD=$HOME/Downloads/linusmemcpy.so
>
> to the Opera shell script so it looks like:
>
> #!/bin/sh
> export OPERA_DIR=${OPERA_DIR:-/usr/share/opera}
> export LD_PRELOAD=$HOME/Downloads/linusmemcpy.so
> exec /usr/lib/opera/opera "$@"
>
> That should do the trick.

THAT DID IT! Thank you so much. I should have thought to try that. I shall share this wealth of knowledge.

[bacole (bacole-redhat-bugs)]

So this bug is marked NOTABUG, yet on the adobe forum, it's still asserted that the bug is in glibc (obviously not strictly correct but that's the conclusion there).

I don't see any bug report in the adobe bug database against flash:

https://bugs.adobe.com/jira/secure/IssueNavigator.jspa?header=FP

Seems like a bug should have been officially submitted to adobe before this bug report got moved to NOTABUG.

It's great that there is a workaround, but expecting all fedora 14 users to compile and maintain their own memcpy until adobe realizes what is wrong is not a very good situation.

[hongjiu.lu (hongjiu.lu-redhat-bugs)]

64bit Fedora 14 is pretty much broken on machines with
SSE4.2. I ran into random crashes with 64bit Fedora 14 on
Intel Core i7. It turns out that 64bit strncasecmp
is broken on machines with SSE 4.2:

https://bugzilla.redhat.com/show_bug.cgi?id=651638

[bacole (bacole-redhat-bugs)]

Ah, sorry I missed
https://bugs.adobe.com/jira/browse/FP-5739
somehow didn't show up in my searches at first.

[belegdol (belegdol-redhat-bugs)]

This bug is mentioned here, in comment 35 to be precise.

[plroskin (plroskin-redhat-bugs)]

Just for the record, the problem playing music and video on vkontakte.ru (a.k.a. vk.com) is also due to this. I tested the site extensively in Firefox with mymemcpy.so preloaded, and almost everything was fine. I was able to get one video to produce the noise, so there must be another, less common problem unrelated to this issue. However, almost everything would play correctly, whereas without mymemcpy.so, I would be lucky if any soundtrack would play.

[jengelh (jengelh-redhat-bugs)]

(In reply to comment #40)
>
> You can call it "crap software" all you like, but the thing is, if memcpy
> doesn't warn about overlaps, there's no test coverage

So let's just add an abort() call to memcpy if it is detected that the areas overlap. Doing so is within the C specification and will surely get everybody their test coverage. Performance degradation, I hear? Limit it to -D_FORTIFY_SOURCE then maybe.

[charlieb-fedora-bugzilla (charlieb-fedora-bugzilla-redhat-bugs)]

(In reply to comment #37)

> DESCRIPTION
> The memcpy() function copies n bytes from memory area src to memory
> area dest. The memory areas should not overlap.

I read that as saying "should". Not "must". memcpy should copy n bytes from memory area src to memory area dest, even if the addresses overlap.

[mjg (mjg-redhat-bugs)]

Is it possible to use symbol versioning to provide applications built against new glibcs with the faster memcpy, without breaking buggy applications that rely on the old behaviour?

[bojan (bojan-redhat-bugs-1)]

(In reply to comment #46)

> The noise on the non-cached case was larger, but the glibc memcpy may have been
> faster. I say "may have been" because it went both ways: I did ten runs, and my
> LD_PRELOAD one still won 6 out of those 10 runs, but the noise was large enough
> that I will allow that I'm not going to guarantee anything.

Out of curiosity, on which CPU what this?

[ccurtis0 (ccurtis0-redhat-bugs)]

(In reply to comment #79)

If you prefer, the POSIX man page for memcpy states: "If copying takes place between objects that overlap, the behavior is undefined." The change history is: "First released in Issue 1. Derived from Issue 1 of the SVID."

http://www.opengroup.org/onlinepubs/009695399/functions/memcpy.html

A quick Google search shows this to be the preferred language. I'm not sure why it differs in the Linux man pages. 'Should' is semantically meaningless - it is either predictable or it is not.

The BSD man page [1993] corroborates:

http://www.unix.com/man-page/FreeBSD/3/memcpy/

BUGS
     In this implementation memcpy() is implemented using bcopy(3), and there-
     fore the strings may overlap. On other systems, copying overlapping
     strings may produce surprises. Programs intended to be portable should
     use memmove(3) when src and dst may overlap.

And here the text from an old version of the GNU C library documentation:

http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_5.html#SEC61

Function: void * memcpy (void *to, const void *from, size_t size)

The memcpy function copies size bytes from the object beginning at from into the object beginning at to. The behavior of this function is undefined if the two arrays to and from overlap; use memmove instead if overlapping is possible.

For others looking back, I also have to note that you omitted the rest of the text from comment #37, which states: "Use memmove(3) if the memory areas do overlap."

[charlieb-fedora-bugzilla (charlieb-fedora-bugzilla-redhat-bugs)]

> If you prefer, the POSIX man page for memcpy states: "If copying takes
> place between objects that overlap, the behavior is undefined."

Yes, for POSIX compliance, it is necessary to assume that the behaviour is
undefined. I doubt, though, that Adobe is claiming POSIX conformance or
portability for its code.

I don't think we are talking about whether glibc/linux *may* change the
implementation while still staying POSIX compliant. We should be talking about
whether glibc/linux *should* change the current behaviour while programs exist
which don't follow the fine (but soft) advice of current documentation, and
will fail if that behaviour changes. That's an issue worthy of discussion,
which can't be decided by references to BSD documentation and POSIX standards.

[bojan (bojan-redhat-bugs-1)]

(In reply to comment #83)

> Yes, for POSIX compliance, it is necessary to assume that the behaviour is
> undefined. I doubt, though, that Adobe is claiming POSIX conformance or
> portability for its code.

Forget POSIX. It's been like this for forever. K&R C book, 2nd edition, page 250.

[siarhei.siamashka (siarhei.siamashka-redhat-bugs)]

(In reply to comment #46)
> (In reply to comment #43)
> > The upside is (ought to be) faster memcpy, which is something that helps a lot
> > of apps.
>
> Hey, I'm a big believer in fast memcpy's, I just don't believe that going
> backwards helps performance.
>
> In the kernel, the optimized x86 memcpy we use is actually a memmove(), because
> while performance is really important, so is repeatability and avoiding
> surprises (strictly speaking, we have two: the "rep movs" version for the case
> where that is supposed to be fast, and the open-coded copy version. The "rep
> movs" version is forwards-only and doesn't handle overlapping areas).
>
> I dunno. I just tested my stupid "mymemcpy.so" against the glibc memcpy() on
> the particular kind of memcpy that valgrid reports (16-byte aligned 1280-byte
> memcpy).
>
> I did both cached (same block over and over) and non-cached (a million blocks
> in sequence).
>
> For the cached case my stupid LD_PRELOAD version was consistently a bit faster.

The same Intel developers submitted a similar optimization to libpixman, and provided the following explanation when asked about about this copying backwards part:
http://lists.freedesktop.org/archives/pixman/2010-August/000423.html

I also was not totally convinced that the backwards copy is really the best solution for the problem:
http://lists.freedesktop.org/archives/pixman/2010-September/000465.html
http://lists.freedesktop.org/archives/pixman/2010-September/000469.html

[timurrrr (timurrrr-redhat-bugs)]

(I'm sorry to jump in the middle of the discussion)

When a program is run under Valgrind it replaces memcpy with its own implementation:
http://code.google.com/p/valgrind-variant/source/browse/trunk/valgrind/memcheck/mc_replace_strmem.c#452

The latter is intentionally overlap-safe, so no surprise it 'fixes' the sound for you.
Plus it throws a Valgrind overlap report like those you've seen.

[freetgm (freetgm-redhat-bugs)]

That's work for me.Thanks

[plroskin (plroskin-redhat-bugs)]

I wonder if libflashsupport could be resurrected to deal with this and further breakages in Adobe flash player. The current libflashplayer code also adds jack support, which is another good thing:
http://repo.or.cz/w/libflashsupport-jack.git

[jgetsoian (jgetsoian-redhat-bugs)]

(In reply to comment #54)
> Verified that this fix works for Firefox as well.
>
> Just replace
> LD_PRELOAD=$(pwd)/mymemcpy.so /opt/google/chrome/google-chrome &
> with
> LD_PRELOAD=$(pwd)/mymemcpy.so /usr/bin/firefox &
>
> (Make sure you've shutdown all running copies of firefox before doing this)

Success on two systems running firefox with this fix. Many thanks!

[jvillalo (jvillalo-redhat-bugs)]

It would be interesting to see if the fix from Comment 19 of:
https://bugzilla.redhat.com/show_bug.cgi?id=651638#c19

Resolves this bug also. There is an updated glibc there.

[charlieb-fedora-bugzilla (charlieb-fedora-bugzilla-redhat-bugs)]

> It would be interesting to see if the fix from Comment 19 of:
> https://bugzilla.redhat.com/show_bug.cgi?id=651638#c19
>
> Resolves this bug also.

I don't see 'resolve regressions in misused memcpy' in the changes list:

    Update from master

        * Fix memory leak in fnmatch
        * Support Intel processor model 6 and model 0x2c
        * Fix comparison in sqrtl for IBM long double
        * Fix one exit path in x86-64 SSE4.2 str{,n}casecmp (BZ#12205, #651638)
        * Fix warnings in __bswap_16 (BZ#12194)
        * Use IFUNC on x86-64 memset
        * Power7-optimized mempcpy
        * Handle uneven cache size in 32bit SSE2 memset (BZ#12191)
        * Verify in ttyname that the symlink is valid (BZ#12167)
        * Update Danish translations
        * Fix concurrency problem between dl_open and dl_iterate_phdr
        * Fix x86-64 strchr propagation of search byte into all bytes of SSE

    register (BZ#12159)

        * Fix perturbing in malloc on free (BZ#12140)
        * PPC/A2 optimized memcpy function
        * Add C99 FP_FAST_FMA{,F,L} macros to <math.h>
        * Check that the running kernel is new enough (#649589)

[jvillalo (jvillalo-redhat-bugs)]

(In reply to comment #91)
> > It would be interesting to see if the fix from Comment 19 of:
> > https://bugzilla.redhat.com/show_bug.cgi?id=651638#c19
> >
> > Resolves this bug also.
>
> I don't see 'resolve regressions in misused memcpy' in the changes list:

That is why I thought it would be interesting to see if it actually does resolve the issue :)

[plroskin (plroskin-redhat-bugs)]

I've tried glibc-2.12.90-19, as it doesn't fix the problem (quite expectedly).

[rstrode (rstrode-redhat-bugs)]

Created attachment 460254
replace all memcpy calls with memmove calls in libflashplayer.so

I wrote this quick and dirty script last night after checking in on this bug report and reading the results. It fixes up the flash plugin to use memmove instead of memcpy across the board. Caveats:

1) The script takes a long time to run (although I don't really know how long since I went off and did other things while it ran)
2) There may be practical performance implications in using memmove where memcpy is okay not sure. Although, comment 46 suggests it may not be that bad of a hit.
3) It works okay for me in that my audio doesn't clip anymore on the one version of libflashplayer.so that I've tried it on, but I haven't done any significant testing.

[ugis.fedora (ugis.fedora-redhat-bugs)]

(In reply to comment #94)
> Created attachment 460254 [details]
> replace all memcpy calls with memmove calls in libflashplayer.so
>

Thanks man, you script works fine for me too. Gonna send fixed plugin to my non-geek brother, who is using fedora only becouse its the only distro that recognises his old usb wifi dongle...

[benuski (benuski-redhat-bugs)]

(In reply to comment #71)
> Add:
>
> export LD_PRELOAD=$HOME/Downloads/linusmemcpy.so
>
> to the Opera shell script so it looks like:
>
> #!/bin/sh
> export OPERA_DIR=${OPERA_DIR:-/usr/share/opera}
> export LD_PRELOAD=$HOME/Downloads/linusmemcpy.so
> exec /usr/lib/opera/opera "$@"
>
> That should do the trick.

In a similar vein, if you run your own version of Firefox, you can add export LD_PRELOAD=$HOME/Downloads/linusmemcpy.so to the run-mozilla.sh file. For me, its in /opt/firefox/. If you scroll most of the way to the bottom of that file, you will see this:
export MOZILLA_FIVE_HOME LD_LIBRARY_PATH
export SHLIB_PATH LIBPATH LIBRARY_PATH ADDON_PATH DYLD_LIBRARY_PATH

Right below that, I added:
export LD_PRELOAD=$HOME/Downloads/linusmemcpy.so

And it works just fine just calling /opt/firefox/firefox, so you can use a toolbar launcher instead of having to launch it from the command line every time.

[pigetak178 (pigetak178-redhat-bugs)]

For a CLOSED NOTABUG bug report, seems to be a lot of traffic on it. Is ANYONE actually fixing this problem either in glibc or in Flash? This is ridiculuous.

[davidsen (davidsen-redhat-bugs)]

(In reply to comment #46)
> (In reply to comment #43)
> > The upside is (ought to be) faster memcpy, which is something that helps a lot
> > of apps.
>
> Hey, I'm a big believer in fast memcpy's, I just don't believe that going
> backwards helps performance.
>

> Do I have a point? I bothered to _measure_ the speed, and according to my
> measurements, glibc wasn't any faster than my trivial version and was likely
> slower. But I only tested two cases.
>
> Regardless, it boils down to: we know the glibc change resulted in problems for
> real users. We do _not_ know that it helped anything at all.
>

The justification of the change was to make memcpy faster *on little processors*. So unless you tested on something other than your usual machine, it may not have given you the relevant data. You never seemed like an ATOM kind of guy. But checking for overlap is just competent software design, not rocket science. We did it in the MULTICS era (late 1960s) in assembler. Omitting a "will this work" check in a library seems shoddy.

[ling.ma (ling.ma-redhat-bugs)]

The blow reason is why to use backward copy, it is good on Core2, NHM, Opteron.
glbc memcpy will prefer to backward/forward copy mode according to offset from source and destination.

Optimize memcpy by avoiding memory false dependece

All read operations after allocation stage can run speculatively,
all write operation will run in program order, and if addresses are
different read may run before older write operation, otherwise wait
until write commit. However CPU don't check each address bit,
so read could fail to recognize different address even they
are in different page.For example if rsi is 0xf004, rdi is 0xe008,
in following operation there will generate big performance latency.
1. movq (%rsi), %rax
2. movq %rax, (%rdi)
3. movq 8(%rsi), %rax
4. movq %rax, 8(%rdi)

If %rsi and rdi were in really the same meory page, there are TRUE
read-after-write dependence because instruction 2 write 0x008 and
instruction 3 read 0x00c, the two address are overlap partially.
Actually there are in different page and no any issues,
but without checking each address bit CPU could think they are
in the same page, and instruction 3 have to wait for instruction 2
to write data into cache from write buffer, then load data from cache,
the cost time read spent is equal to mfence instruction. We may avoid it by
tuning operation sequence as follow.

1. movq 8(%rsi), %rax
2. movq %rax, 8(%rdi)
3. movq (%rsi), %rax
4. movq %rax, (%rdi)

Instruction 3 read 0x004, instruction 2 write address 0x010, no any
dependence. At last on Core2 we gain 1.83x speedup compared with
original instruction sequence. In this patch we first handle small
size(less 20bytes), then jump to different copy mode. Based on our
micro-benchmark small bytes from 1 to 127 bytes, we got up to 2X
improvement, and up to 1.5X improvement for 1024 bytes on Corei7.

Thanks
Ling

[shur (shur-redhat-bugs)]

Since the Atom processor is mentioned, I noticed that this problem didn't occur on my Toshiba netbook with a N455 atom processor, but was intolerable on a laptop with dual core Pentium, both with updated Fedora 14.

I am not much affected by this problem, but I do think if you are serious about offering Linux on the desktop, you have to either make it work with Adobe flash, or state publicly that you don't support it. The average user doesn't care squat about whether the coding follows the rules or arguments over who is responsible if it doesn't work. If it works on Win 7 and doesn't work on Fedora, it is Fedora and Linux that take the crap. Period.

[torvalds (torvalds-redhat-bugs)]

I'd personally suggest that glibc just alias memcpy() to memmove().

Yes, clearly overlapping memcpy's are invalid code, but equally clearly they do happen. And from a user perspective, what's the advantage of doing the wrong thing when you could just do the right thing? Optimize the hell out of memmove(), by all means.

Of course, it would be even better if the distro also made it easy for developers to see the bad memcpy's, so that they can fix their apps. Even if they'd _work_ fine (due to the memcpy just doing the RightThing(tm)), fixing the app is also the right thing to do, and this would just make Fedora and glibc look good.

Rather than make it look bad in the eyes of users who really don't care _why_ flash doesn't work, they just see it not working right.

There is no advantage to being just difficult and saying "that app does something that it shouldn't do, so who cares?". That's not going to help the _user_, is it?

And what was the point of making a distro again? Was it to teach everybody a lesson, or was it to give the user a nice experience?

[yann (yann-redhat-bugs-1)]

(In reply to comment #101)

> Of course, it would be even better if the distro also made it easy for
> developers to see the bad memcpy's, so that they can fix their apps. Even if
> they'd _work_ fine (due to the memcpy just doing the RightThing(tm)), fixing
> the app is also the right thing to do, and this would just make Fedora and
> glibc look good.
>

This is probably already done: using -D_FORTIFY_SOURCE=1 enable use of
__builtin___memcpy_chk()

[mglantz (mglantz-redhat-bugs)]

From https://bugs.adobe.com/jira/browse/FP-5739
Shu Wang added a comment - 11/16/10 02:30 AM
Thanks very much for all your time to report the issue. Flash Player team is looking into it. Thanks.

I've emailed Shu Wang at Adobe to see if he can give a time estimate on fixing this.

[mglantz (mglantz-redhat-bugs)]

Shu Wang at Adobe told me that the Flash Player team is actively investigating the issue. They have no time estimate to share yet. I'll update this BZ as I get updated information.

[mglantz (mglantz-redhat-bugs)]

Here's the bomb:
Adobe says it may take months for them to fix this.

[pinto.elia (pinto.elia-redhat-bugs)]

What is strange for a proprietary product ? :=) It is the norm.

[mglantz (mglantz-redhat-bugs)]

I request this bug to be re-opened.

Seriously degraded flash, for months, in Fedora seems much to much for at least me. This may cause more than a few users to change to other Linux distributions.

Andreas Schwab, can you roll back this change or make it work with Adobe Flash by some other means?

[andrei.ilie (andrei.ilie-redhat-bugs)]

Why not use f13 until Adobe releses an updated flash ?

[andrei.ilie (andrei.ilie-redhat-bugs)]

(In reply to comment #110)
> Why not use f13 until Adobe releses an updated flash ?

...or downgrade glibc

[m.a.young (m.a.young-redhat-bugs)]

There is now a FESCo ticket about this issue at https://fedorahosted.org/fesco/ticket/501

[ugis.fedora (ugis.fedora-redhat-bugs)]

(In reply to comment #111)
> (In reply to comment #110)
> > Why not use f13 until Adobe releses an updated flash ?
>
> ...or downgrade glibc

Or use Ray Strode's script to patch libflashplayer.so ...

[oliver.henshaw (oliver.henshaw-redhat-bugs)]

(In reply to comment #107)
> Here's the bomb:
> Adobe says it may take months for them to fix this.

Could you give a link to this statement? I couldn't see it in the adobe bug, and don't know where else to look.

[mglantz (mglantz-redhat-bugs)]

(In reply to comment #114)
> (In reply to comment #107)
> > Here's the bomb:
> > Adobe says it may take months for them to fix this.
>
> Could you give a link to this statement? I couldn't see it in the adobe bug,
> and don't know where else to look.
There is no link, I e-mailed Shu Wang at Adobe.

[yann (yann-redhat-bugs-1)]

(In reply to comment #102)
> (In reply to comment #101)
>
> > Of course, it would be even better if the distro also made it easy for
> > developers to see the bad memcpy's, so that they can fix their apps.
>
> This is probably already done: using -D_FORTIFY_SOURCE=1 enable use of
> __builtin___memcpy_chk()

Nope.

When looking at glibc (and gcc), _FORTIFY_SOURCE only enable checks for
overflow, not overlap.

[mglantz (mglantz-redhat-bugs)]

(In reply to comment #94)
> Created attachment 460254 [details]
> replace all memcpy calls with memmove calls in libflashplayer.so
>
> I wrote this quick and dirty script last night after checking in on this bug
> report and reading the results. It fixes up the flash plugin to use memmove
> instead of memcpy across the board. Caveats:
>
> 1) The script takes a long time to run (although I don't really know how long
> since I went off and did other things while it ran)
> 2) There may be practical performance implications in using memmove where
> memcpy is okay not sure. Although, comment 46 suggests it may not be that bad
> of a hit.
> 3) It works okay for me in that my audio doesn't clip anymore on the one
> version of libflashplayer.so that I've tried it on, but I haven't done any
> significant testing.
Works excellent for me! The script took 1-2 minutes to run on my laptop.

In short for anyone ending up here, you may try this to bypass the issue:
In a terminal, run:

wget https://bugzilla.redhat.com/attachment.cgi?id=460254 -O ~/Downloads/memcpy-to-memmove.sh
chmod +x ~/Downloads/memcpy-to-memmove.sh
cp /path/to/your/libflashplayer.so /path/to/your/libflashplayer.so.backup
~/Downloads/memcpy-to-memmove.sh /path/to/your/libflashplayer.so

[mglantz (mglantz-redhat-bugs)]

Good new, I just got an e-mail from Adobe, saying..

..they have a fix
..the fix has been send to QA/QE

They say that they cannot commit to any dates, but that they are taking the issue seriously.

I told them that if they want volunteers trying out their fix, we can help.

[plroskin (plroskin-redhat-bugs)]

Since there is no ETA from Adobe, I think we should consider a fix for the time being. I'm just trying to brainstorm the problem. Possible solutions could be:

1) Revert the glibc change. While I don't think that a perfectly good change in glibc should be reverted to placate a proprietary plugin, this is not a perfectly good change. It's essentially a workaround for a defect in some Intel processors. It may improve benchmarks, but we can and should ask about real life benefits. While operations on short arrays may become faster in some very specific cases, copying of large and well-aligned arrays is likely be slowed down by going backwards.

2) Add a wrapper to Firefox to use memmove() instead of memcpy(). Users of other browsers will do it for themselves.

3) I don't know if it's feasible, but maybe nspluginwrapper could be changed to intercept the memcpy() call from the plugins. Maybe another wrapper could be bundled with nspluginwrapper.

4) Another wrapper could be written for flash plugin. That wrapper should be part of the flash-plugin package, and it should be very strongly recommended by the fedora Flash page (http://fedoraproject.org/wiki/Flash)

5) The flash-plugin package should patch the plugin on install. rpm verification will fail, but perhaps it's OK. We could mark the plugin as a "configuration file".

6) The flash-plugin package should patch the plugin at the build time. This could have legal consequences, but I don't think Adobe would actually enforce them considering that the change is purely to fix a flaw in their product.

[oliver.henshaw (oliver.henshaw-redhat-bugs)]

Isn't nspluginwrapper unnecessary now that firefox has Out-of-Process-Plugins (i.e. plugin-container)? I honestly don't know what utility nspluginwrapper has remainiig to it, but suggestion #3 may amount to suggestion #2.

Re: suggestions #4-6 - isn't the flash-plugin package provided by adobe itself?

[plroskin (plroskin-redhat-bugs)]

There is an alternative package by Leigh Scott, mentioned on http://fedoraproject.org/wiki/Flash

It already includes a thin wrapper adding support for Athlon64 processors without support for the lahf instruction. I tried just adding a safe memcpy() implementation to that file, but it didn't work.

I realize that it would be problematic to get ordinary users to use that repository, so integration of the fix with with nspluginwrapper, firefox or glibc would be preferable.

[paulius.zaleckas (paulius.zaleckas-redhat-bugs)]

Created attachment 461740
binary patch for "flashplayer_square_p2_64bit_linux_092710"

use bspatch from bsdiff package to apply this patch.

This patch changes only one byte in libflashplayer.so. I did this manually with hexedit after studying objdump -S output. The idea behind this change is not to replace every memcpy call with memmove one, but to alter dynamic symbol table to point to memmove instead of memcpy.
I hope someone can make a similar script like Ray Strode did, but using this less intrusive method.

[vvaldez (vvaldez-redhat-bugs)]

Comment #38 worked for me, thanks Linus!

[reg.bugs (reg.bugs-redhat-bugs)]

I tried the binary patch from comment #122, it works too.

[dornelas (dornelas-redhat-bugs)]

I also tried the binary patch from comment #122, and it's been working without any problems so far. Here's the general command for applying the patch:

    bspatch libflashplayer.so libflashplayer.sonew flash_64.bsdiff

[n.underwood78 (n.underwood78-redhat-bugs)]

(In reply to comment #122)
> Created attachment 461740 [details]
> binary patch for "flashplayer_square_p2_64bit_linux_092710"
>
> use bspatch from bsdiff package to apply this patch.
>
> This patch changes only one byte in libflashplayer.so. I did this manually with
> hexedit after studying objdump -S output. The idea behind this change is not to
> replace every memcpy call with memmove one, but to alter dynamic symbol table
> to point to memmove instead of memcpy.
> I hope someone can make a similar script like Ray Strode did, but using this
> less intrusive method.

This patch does not work for rekonq. Works fine for me with konqueror, firefox, chromium & google-chrome however. Rekonq still has the same sound issues. Anyone know where rekonq looks for plugins? I've installed the patched version of libflashplayer.so to:

/usr/lib/opera/plugins/libflashplayer.so
/usr/lib64/chromium-browser/plugins/libflashplayer.so
/usr/lib64/flash-plugin/libflashplayer.so
/usr/lib64/mozilla/plugins/libflashplayer.so
/usr/lib64/seamonkey-2.0.10/plugins/libflashplayer.so

And all the corresponding browsers work, except for rekonq.

[robin.bowes (robin.bowes-redhat-bugs)]

Well, after enduring crappy flash sound since November 2, I finally stumbled across this bug.

I have implemented the workaround as per comment #55 and it is working for me.

I just want to comment that it is *ridiculous* that this issue has been closed as "NOTABUG" - it quite manifestly *is* a bug.

I'm no great fan of flash but it's an essential part of life on the web these days and I had thought that the Fedora project had finally put its days of broken flash support behind it.

The average punter, looking to evaluate Fedora will *not* care one jot *why* sound is broken in flash audio/video - they will just think "Fedora is crap" and move on to something else that isn't broken.

Please, re-open this issue and get a fix implemented for it ASAP.

[robatino (robatino-redhat-bugs)]

(In reply to comment #127)

> I just want to comment that it is *ridiculous* that this issue has been closed
> as "NOTABUG" - it quite manifestly *is* a bug.

In Adobe's software.

> I'm no great fan of flash but it's an essential part of life on the web these
> days and I had thought that the Fedora project had finally put its days of
> broken flash support behind it.

Fedora's flash support is fine. Adobe's software is broken.

> The average punter, looking to evaluate Fedora will *not* care one jot *why*
> sound is broken in flash audio/video - they will just think "Fedora is crap"
> and move on to something else that isn't broken.

That's fine. Fedora Project's main priority is to improve its own software, not necessarily to maximize the number of users (unlike proprietary software, where maximizing the number of paid users is an end in itself). In particular, developers shouldn't waste time creating workarounds for third-party software and as a result causing developers of said software to be even less responsive than they already are, creating the need for more workarounds, ad infinitum.

> Please, re-open this issue and get a fix implemented for it ASAP.

Anything done in Fedora is a workaround, not a fix. Only Adobe can fix its own software.

In any case, it looks like Adobe may have "fixed" the problem in their usual responsive fashion. The latest update at http://labs.adobe.com/downloads/flashplayer10.html shows only 32-bit versions. If they have in fact abandoned 64-bit Flash yet again, it means that users have no choice but to use the 32-bit wrapped plugin which is not affected by this bug (in their software).

[torvalds (torvalds-redhat-bugs)]

(In reply to comment #128)
>
> In Adobe's software.
>
> > I'm no great fan of flash but it's an essential part of life on the web these
> > days and I had thought that the Fedora project had finally put its days of
> > broken flash support behind it.
>
> Fedora's flash support is fine. Adobe's software is broken.

Quite frankly, I find your attitude to be annoying and downright stupid.

How hard can it be to understand the following simple sentence:

   THE USER DOESN'T CARE.

Pushing the blame around doesn't help anybody. The only thing that helps is Fedora being helpful, not being obstinate.

Also, the fact is, that from a Q&A standpoint, a memcpy() that "just does the right thing" is simply _better_. Quoting standards is just stupid, when there's two simple choices: "it works" or "it doesn't work because bugs happen".

Standards are paper. I use paper to wipe my butt every day. That's how much that paper is worth.

Reality is what matters. When glibc changed memcpy, it created problems. Saying "not my problem" is irresponsible when it hurts users.

And pointing fingers at Adobe and blaming them for creating bad software is _doubly_ irresponsible if you are then not willing to set a higher standard for your own project. And "not my problem" is not a higher standard.

So please just fix it.

The easy and technically nice solution is to just say "we'll alias memcpy to memmove - good software should never notice, and it helps bad software and a known problem".

[robatino (robatino-redhat-bugs)]

(In reply to comment #129)

> Also, the fact is, that from a Q&A standpoint, a memcpy() that "just does the
> right thing" is simply _better_.

Assuming memcpy() (the existing one) is never more efficient than memmove(). If this is in fact known to _always_ be the case today, then I would agree. Otherwise, it's a bad idea. Optimized functions should continue to be available for those who need them, and it's not like Adobe didn't have a few decades of advance notice on how to code these functions properly. Anyone who finds that memmove() is just as fast in a particular case is free to use it.

> The easy and technically nice solution is to just say "we'll alias memcpy to
> memmove - good software should never notice, and it helps bad software and a
> known problem".

Good software _will_ notice, if it's using memcpy() deliberately, for better performance, and doesn't want it aliased. It's equally easy for Adobe (or anyone else) to just do a global search and replace in their own code, so as not to slow down everyone else's. But as mentioned above, it appears that they've abandoned their own 64-bit plugin again, so the "known problem" is gone - unless by their next version, they still haven't figured out the difference.

[mike (mike-redhat-bugs-1)]

Andre, no one has abandoned anything. The Adobe website was just poorly updated. The 64-bit plugin was updated[1]. I am running on a *64-bit* Flash plugin version 10.3.162.29. The memcpy() issue is not fixed though. The date stamp is on 2010-11-16, which is around the time the issue was reported, but obviously too old.

As far as Fedora is concerned, I believe all of us here are free to make Fedora what we want. I don't know of any particular Fedora policy (please name one if I am wrong) that prevents any one of us from applying a workaround (be it glibc, be it nspluginwrapper, etc) that helps users *use* Fedora. Being petty and small and telling users to "get lost" makes me disgusted to be considered a Fedora contributor.

P.S. There's a bit much political BS in this bug, which is closed. It may be best to hold further comments until the results of tomorrow's FESCO meeting are known.

[1] http://labs.adobe.com/downloads/flashplayer10_square.html

[torvalds (torvalds-redhat-bugs)]

(In reply to comment #130)
>
> Good software _will_ notice, if it's using memcpy() deliberately, for better
> performance, and doesn't want it aliased.

Bullshit. You clearly don't know what you're talking about.

There are exactly two reasons for memmove() existing in the first place:

 (a) memcpy() hasn't necessarily handled overlapping areas, so people had to make up a new function just because you couldn't _rely_ on memcpy working right for that case.

   IOW, it's not an issue of "memcpy shouldn't handle overlapping areas automatically", but a "you can't rely on it even if it does, so for portability reasons you shouldn't".

 (b) you can make a _simpler_ memcpy() if you assume there are no overlapping areas (which is obviously the reason why memcpy originally didn't). But the "simpler" is really trivial - the traditional difference between memcpy and memmove is literally that memcpy always copied upwards, and memmove() simply just checks whether the destination address is above the source address and decides to copy backwards if so.

And quite frankly, neither excuse is valid these days for not just aliasing the two to the same thing (and make both do memmove).

There is no performance difference. The "is it overlapping" is about two small and fast instructions (no cache issues etc), depending on just how exact you want to do it (ie again, traditionally it's just that single compare and conditional jump - but you can be more precise if you want to by adding just a few more instructions).

In fact, I can pretty much guarantee that if you have a program that notices the one or two cycles of the overlapping check, then you have a program that actually prefers the _old_ glibc memcpy(), the simpler one that worked fine with the flash player too. The traditional one that always moved things upwards.

Because the whole bug was introduced by the change (did you take a look at glibc sources? I did) that made memcpy() _much_ more complicated, and now it does computed indirect jumps based on size etc. So the new-and-improved one is the one that takes a lot more cycles, exactly because it tries to handle the special cases. But then it doesn't handle the _simple_ special case of "is it overlapping?".

In short: there is simply no excuse for the current memcpy() behavior. It doesn't match historical behavior, so it breaks existing applications. And there is certainly no "simplicity" argument: if you want a simpler and more maintainable glibc code base, you just say "let's do memcpy and memmove with the same code, and not have those ugly #ifdef's and duplicate compilations".

And there is no performance argument. None. If the argument is that "memcpy()" should be as simple as possible and have minimal overhead and perform best for the case where a single cycle matters (ie everything cached, nicely aligned arguments etc), then the glibc changes should just be reverted entirely.

So either re-instate the old traditional behavior ("memcpy is simple") that at least has some _historical_ reason behind it, and that makes flash work again.

Or alternatively, just make memcpy DTRT automatically. The check for overlap is not going to be noticed. And _not_ c...

[robatino (robatino-redhat-bugs)]

Assuming your analysis is correct, aliasing memcpy() to memmove() would be preferable, since maintaining the extra code just to save one or two cycles per call isn't worth it IMO. And the bug Summary could be changed to something like "alias memcpy() to memmove()", since improving the GCC code itself is enough reason to make the change, regardless of whether broken applications are more likely to work. (Just wondering about the affect on application size, though - how different is the size of the memcpy() and memmove() code, and how often are they inlined? I'm guessing this is not a real issue, but it's the only other one I can think of.)

[kevin (kevin-redhat-bugs-1)]

The latest flash 64bit plugin seems to have fixed this:

http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_2_p3_64bit_linux_111710.tar.gz

(At least it fixes it fine here).

As to reverting this due to technical arguments like https://bugzilla.redhat.com/show_bug.cgi?id=638477#c132 could the glibc maintainers please consider that and reply here? If they wish to close this bug again, thats their right, but one more revisit and reply to the technical arguments would be welcome.

Thanks.

[m.a.young (m.a.young-redhat-bugs)]

(In reply to comment #134)
> The latest flash 64bit plugin seems to have fixed this:
>
> http://download.macromedia.com/pub/labs/flashplayer10/flashplayer10_2_p3_64bit_linux_111710.tar.gz
>
> (At least it fixes it fine here).

It is still broken for me. Maybe some of your workarounds are still in place.

[kevin (kevin-redhat-bugs-1)]

Sigh. My bad. It's still broken in that version too.

I tested a handfull of random youtube videos, but they were all ones that didn't have the bitrate that shows this. ;(

So, yes, it's still broken. Use the workarounds or 32bit official plugin with nspluginwrapper.
Sorry for the false alarm.

[chris.stone (chris.stone-redhat-bugs)]

OH MY GOD! I just tried Ray Strode's patch and not only does not fix the sound bug, but it makes flash WAY MORE STABLE! I used to get flash crashing on me all the time whenever I played several videos at once, and now I'm noticing that I no longer see any crashes at all! Incredible!

[chris.stone (chris.stone-redhat-bugs)]

oopse that should have read "not only does fix the sound bug" :o

[gsking1 (gsking1-redhat-bugs)]

I just encountered this bug while previewing mp3s on the Amazon mp3 download website and was able to workaround by using #38/#55. However, I'd like to note that this is type of bug is is especially frustrating since after reading the comments above it smells too political and idealistic.

Please be reminded that according to the Fedora front page http://fedoraproject.org/en/, it is supposed to be stable and for everyday use. This update clearly broke some of that stability whatever the cause. There are many people (my mom and many co-workers) that would not have any clue as to how to fix this even with the workaround posted here.

I would recommend that a notice be put on the fedora website or help page http://fedoraproject.org/en/get-help that references this bug or provides information as it apparently affects quite a few websites and both google-chrome and firefox.

Regards, Geoff

[pigetak178 (pigetak178-redhat-bugs)]

Good comments, GS, but from the above discussion, it is apparent that Fedora is not meant for "users" but for "contributers". Your mom and coworkers would be better off with Ubuntu. If Fedora keeps going in the direction it is, Ubuntu might end up with a few more followers and Fedora with a few less. I want a Linux system that works. I've put up with Fedora's "purity" policies from the beginning, but this one might be the last straw up with which this camel will not put.

[jgetsoian (jgetsoian-redhat-bugs)]

(In reply to comment #137)
> OH MY GOD! I just tried Ray Strode's patch and not only does not fix the sound
> bug, but it makes flash WAY MORE STABLE! I used to get flash crashing on me
> all the time whenever I played several videos at once, and now I'm noticing
> that I no longer see any crashes at all! Incredible!

Indeed. I updates from Linus' patched memcpy preload to Ray Strode's patch and all the the little hesitations and timing stumbles I'd always gotten on some sites disappeared.

[fedora (fedora-redhat-bugs-1)]

I'm an average user that experiences distorted sound at full-screen videos from YouTube (such as http://www.youtube.com/user/jamesbluntmusic#p/u/0/x1yOGhnmYfI) or from Colbert Nation (http://www.colbertnation.com/the-colbert-report-videos/367133/).

Since my processor is 32 bits and not 64 bits, I wonder whether it is the same bug as mine.

I have tried to compile the code from comment 55, but I'm afraid I get the following error:

  $ gcc -O2 -c linusmemcpy.c
  linusmemcpy.c: Assembler messages:
  linusmemcpy.c:6: Error: number of operands mismatch for `movs'

This is all Greek to me. Any idea on how to fix this?

Many thanks for your help,

Pablo

[mail2benny (mail2benny-redhat-bugs)]

Created attachment 465094
The patched flashplayer plugin 10_2_p3_64bit 111710

Just install this plugin instead of the adobe one and everything should work. I fixed the adobe one it with Ray Strode's script.

[jkeating (jkeating-redhat-bugs)]

(In reply to comment #143)
> Created attachment 465094 [details]
> The patched flashplayer plugin 10_2_p3_64bit 111710
>
> Just install this plugin instead of the adobe one and everything should work. I
> fixed the adobe one it with Ray Strode's script.

This is likely something we should not be distributing.

[sverrel (sverrel-redhat-bugs)]

Please do - trying to get to the attached pre patched flashplayer #143 - give me permission denied :(

[m.a.young (m.a.young-redhat-bugs)]

(In reply to comment #145)
> Please do - trying to get to the attached pre patched flashplayer #143 - give
> me permission denied :(

Posting a patched version of flash player breaks the license http://labs.adobe.com/technologies/eula/flashplayer10.html (in two places I think) which will be why access to that file has been removed.

[mail2benny (mail2benny-redhat-bugs)]

My deepest apologies for breaking the license. It wont happen again... I was just trying to help some people who got mixed up in all the amount of comments here...

For users who still have problems:
I "incidentally found" the file here: http://rapidshare.com/files/435418850/flashplayer10_2_p3_64bit_linux_111710.tar.gz

[sverrel (sverrel-redhat-bugs)]

Great find Benny ! Worked like a sharm :) Thank !!

[e_redhat (eredhat-redhat-bugs)]

I've been using RedHat since RedHat used to release a binary desktop, before they created the Fedora Project. I've used Fedora and Centos for non-profit uses since, including for OpenStandards.net and personal use.

When I installed the 64-bit Fedora, and had to go through a pain to install 64-bit Flash, I used to, but unhappy with, the process for installing such a critical component.

When recently installing Ubuntu on a friend's Netbook to "correct" her Windows virus problem, I couldn't believe how easy it was to install Flash. It was a check box on the normal install process! I found out non-technical friends were installing Ubuntu and very happy with it. This was obviously because Ubuntu make it possible for a non-technical person to install Flash. We all know that if you replace Windows with Ubuntu for a friend, and do not install Flash, they will call you pretty quickly asking why they can't view things on the web.

I've noticed the sound problem with Fedora, narrowing it down to just the web browsers, both Firefox and Chrome. Adding the lack of a Boxee build for Fedora, and I've been telling all non-technical friends to install Ubuntu. I've described Fedora as an unstable experimental version designed only for technical people. (To be sure, previous incidents with the nVidia driver leading me to have to re-install Fedora after a kernel update caused the loss of video, and paranoia that this can happen again, fed into this conclusion.)

Then, I found and read this thread. I used Ray's patch to correct my sound problem. Thanks, Ray!

I concur 100% with Linus on this one. The changes to glibc need to be rolled back in an update to Fedora 14 until Adobe corrects their Flash binary! If you don't do this, there will be a lot more people like me, who, seeing only the surface, will tell everyone to install Ubuntu. This needs to be done immediately! People have over 4 GB of ram in new computers, and they need the 64-bit version to use it.

I'm glad to see there are people like Linus that would like to see Fedora become a mainstream desktop, and not just an experimental distribution for technical people. I hope those in control will learn from this and not only roll back the glibc change ASAP, but also look into streamlining the Flash install like Ubuntu did so non-technical people can have it when they install Fedora with default settings.

[reg.bugs (reg.bugs-redhat-bugs)]

I'd like to point out that malloc() has its MALLOC_CHECK_ environment variable which activates less efficient implementation designed to be tolerant
against simple errors.

Memcpy() bugs happen just like malloc() bugs do. So why not a MEMCPY_CHECK_ ?

[mail2benny (mail2benny-redhat-bugs)]

(In reply to comment #149)

Hear hear.

[whizzman (whizzman-redhat-bugs)]

One more supporter for Linus' plea. End users don't care what the cause is, they want it fixed. Sure, Adobe is making themselves look bad by taking way too long to patch this. Even an intermediate fix, just for this problem, can be pushed through bureaucratic mazes in just a few days. However, this is not taking the responsibility away from Fedora to make things "just work".

I, being someone that is heavily into performance tuning, think that winning cycles, no matter how little, in often used functions is a good thing(tm). Therefor, I agree that improving glibc by doing these optimizations should be done.

Several workarounds have been mentioned to either mitigate the problem in glibc, or to provide a workaround somewhere else in Fedora. Neither has been done, in over a month and over 100 comments on this bug. Given the amount of updates I receive daily for FC14, I think this is an issue that should have been dealt with long ago. No way is it possible that nobody with write access to the relevant packages hasn't had any time to deal with this yet.

I would like to urge anyone with any political power withing Fedora to get this problem dealt with immediately. An organization this big and mature shouldn't be having trouble dealing with this sort of thing, fix it, make certain it won't happen again and move on.

[davidsen (davidsen-redhat-bugs)]

(In reply to comment #149)

> I concur 100% with Linus on this one. The changes to glibc need to be rolled
> back in an update to Fedora 14 until Adobe corrects their Flash binary! If you
> don't do this, there will be a lot more people like me, who, seeing only the
> surface, will tell everyone to install Ubuntu. This needs to be done
> immediately! People have over 4 GB of ram in new computers, and they need the
> 64-bit version to use it.

This is a fine urban myth, but only that. The 32 bit "PAE" kernel can address 36 bits of memory space, or 64GB of physical RAM. The only real benefit would be to people who have a single user process limited by 4GB of RAM, and that's a very small number. If you compile your own apps for 64 bit, with the right options and use the right algorithms, you might see about a 5% speedup due to more registers. I have never seen that in any RPM distributed Fedora software, and I would love 5% faster ffmpeg.

I humbly advise that given my lack of drama with 24GB RAM and PAE, and lack of issues running better supported 32 bit apps, that people stay with 32 bit PAE unless they have a specific reason to go 64. I know it's not the "next big thing" but it works and uses all your memory.

[kevin (kevin-redhat-bugs-1)]

Pretty please with sugar on top, could people please refrain from adding comments here that are not technical in nature? I have asked the maintainers to revisit this based on the technical arguments.

I would suggest to those that need flash working now that you use the 32bit flash plugin with nspluginwrapper. See: http://fedoraproject.org/wiki/Flash for information on installing it. As this is in fact the only released and security updated flash plugin adobe ships (the 64bit one is a beta and doesn't promise security releases).

Adding non technical comments just makes it less likely that maintainers will be able to filter out those and revisit this. Thanks.

[hdfssk (hdfssk-redhat-bugs)]

Would someone who's allowed please add the CommonBugs keyword to this bug? It'll save a lot of folks search time once it's listed on the http://fedoraproject.org/wiki/Bugs/Common page.

[awilliam (awilliam-redhat-bugs)]

anyone can add keywords, I think.

[alehman (alehman-redhat-bugs)]

In replay to comment #147, this seemed to correct the problem for Youtube/240P, but not for some others, such as:
http://bestofthebaytv.com/view/1275/Salesjobscom

Fedora 14, 64 bit

[jgetsoian (jgetsoian-redhat-bugs)]

RE: comment 157

The site referenced plays OK here (Firefox 3.6.13) using Ray Strode's patch (comment 94)

[jaceks (jaceks-redhat-bugs)]

Just wanted to say, that there's the same problem with Rhythmbox. When I wanted to play BBC Radio 4 podcasts, I got similar distorted sound.
Using mymemcpy from comment #38 also helps.

Jacek

[sergio (sergio-redhat-bugs-1)]

Comment 94 also fix sound problem for me

[alehman (alehman-redhat-bugs)]

That seemed to work for me as well.

[promac (promac-redhat-bugs)]

MPD (Music Player Daemon - http://mpd.wikia.com/wiki/Music_Player_Daemon_Wiki) can be set to output an http stream, which is processed by the totem plugin in firefox.

MPD is also being affected by this bug, and it has nothing to do with the flash-plugin. The fix on comment #38 (Linus Torvalds) works just fine in this case, though.

I also have an .src.rpm that applies the fix on comment #94 (Ray Strode) during
the build, that is, it brings an unmodified flash-plugin an applies
the script when the rpm is created for 64 bits:

http://orion.lcg.ufrj.br/RPMS/src/flash-plugin-10.3-1.fc14.src.rpm

    File: libflashplayer.so
    Version:
    Shockwave Flash 10.3 d162

[promac (promac-redhat-bugs)]

The real problem is gstreamer.

Just try to play an avi (e.g., with divx codec) using gst123 or totem,
and the sound will be completely distorted.

The fix on comment #38 also solves the problem.

[promac (promac-redhat-bugs)]

I tracked down the problem using valgrind,
and the culprit was a libgstflump3dec.so
in my ~/.gstreamer-0.10/plugins/

This plugin was dated from 2007. After deleting it,
gstreamer is working just fine.

However, this plugin has never caused any trouble before, though.

[pigetak178 (pigetak178-redhat-bugs)]

#164, nice work. You found another "proprietary" binary that used the *bad* memcpy for overlapping memory.

[rh_bugzilla (rhbugzilla-redhat-bugs-1)]

#164: nice find. did you report this to Fluendo?

[promac (promac-redhat-bugs)]

Another person has already emailed Fluendo directly.

I also have Linux Torvalds' solution here:

http://orion.lcg.ufrj.br/RPMS/src/memcpy-1.0-1.fc14.src.rpm

It installs a fixed memcpy in /opt/memcpy and provides a script in /usr/bin
that preloads it to a given program:

memcpy-preload.sh prog_name prog_arguments

for instance:

memcpy-preload.sh google-chrome

Booth solutions are equivalent in terms of fixing the 64 bit flash-plugin, but this one can be applied to other programs as well.

[fedora (fedora-redhat-bugs-1)]

(In reply to comment #167)
> I also have Linux Torvalds' solution here:
>
> http://orion.lcg.ufrj.br/RPMS/src/memcpy-1.0-1.fc14.src.rpm

I'm extremely interested in your fix.

As I already reported (comment 142), I experience a similar problem in Flash when played at full screen (Fedora 13 played the videos fine, but Fedora 14 distorts their audio)

I'm on 32bit and I cannot compile it due to the following error:

+ ./make-mymemcpy.sh
mymemcpy.c: Assembler messages:
mymemcpy.c:6: Error: number of operands mismatch for `movs'
mymemcpy.o: could not read symbols: File in wrong format

Is there any way I can compile it under 32bits?

Thanks for your help and happy New Year to everybody,

Pablo

[john.robinson (john.robinson-redhat-bugs)]

(In reply to comment #168)
[...]
> I'm on 32bit and I cannot compile it

Pablo, Ray Strode's script in comment #94 should work on 32 bits as well.

[promac (promac-redhat-bugs)]

(In reply to comment #168)
> (In reply to comment #167)
> > I also have Linux Torvalds' solution here:
> >
> > http://orion.lcg.ufrj.br/RPMS/src/memcpy-1.0-1.fc14.src.rpm
>
> I'm extremely interested in your fix.
>
> As I already reported (comment 142), I experience a similar problem in Flash
> when played at full screen (Fedora 13 played the videos fine, but Fedora 14
> distorts their audio)
>
> I'm on 32bit and I cannot compile it due to the following error:
>
> + ./make-mymemcpy.sh
> mymemcpy.c: Assembler messages:
> mymemcpy.c:6: Error: number of operands mismatch for `movs'
> mymemcpy.o: could not read symbols: File in wrong format
>
> Is there any way I can compile it under 32bits?
>
> Thanks for your help and happy New Year to everybody,

The code is written in assembler, and is intended to 64 bits.
That is why you can not compile it.

I can play both videos fine (#142), but only the James Blunt's video goes to full screen here.

However, I think your issue is different. The memcpy problem in flash 64 bits makes the sound unrecognisable, and it is not a simple stuttering or something like that.

As John said in comment #161, Ray Strode's script replaces all memcpy calls for
memove, and can be applied in 32 bits (although my .src.rpm only applies the script for 64 bits).

[hidoufr (hidoufr-redhat-bugs)]

*** Bug 663784 has been marked as a duplicate of this bug. ***

[fedora (fedora-redhat-bugs-1)]

(In reply to comment #170)
> The code is written in assembler, and is intended to 64 bits.
> That is why you can not compile it.

Thanks for your replies, Paulo and John.

I had no idea that the code was written in assembler (I'm only a user, not a programmer, so all code is Greek to me).

> However, I think your issue is different. The memcpy problem in flash 64 bits
> makes the sound unrecognisable, and it is not a simple stuttering or something
> like that.

I know that it is different, but it might have the same cause. I already reported it (bug 661385). But since I had no reply, I wanted to try whether any of these fixes could work.

> As John said in comment #161, Ray Strode's script replaces all memcpy calls for
> memove, and can be applied in 32 bits (although my .src.rpm only applies the
> script for 64 bits).

I have downloaded the script, but invoking "./fix-flash.sh /usr/bin/firefox" gives me the following warning:

./fix-flash.sh /usr/bin/firefox
objdump: /usr/bin/firefox: File format not recognized
objdump: Section '.plt' mentioned in a -j option, but not found in any input file
Can't find memcpy call in /usr/bin/firefox PLT

Sorry, but again it's Greek to me. How should I use the fix?

Thanks for your help,

Pablo

[ml-bz-dale (ml-bz-dale-redhat-bugs)]

Re Comment 172

You can't patch /usr/bin/firefox because (under Fedora, at least) it is
a bash script that in turn runs the firefox binary, which currently (Fedora 13)
is /usr/lib/firefox-3.6/firefox . If you wish, try patching that:

./fix-flash.sh /usr/lib/firefox-3.6/firefox

[fedora (fedora-redhat-bugs-1)]

(In reply to comment #173)
> Re Comment 172
>
> You can't patch /usr/bin/firefox because (under Fedora, at least) it is
> a bash script that in turn runs the firefox binary, which currently (Fedora 13)
> is /usr/lib/firefox-3.6/firefox . If you wish, try patching that:

Thanks, Dale.

I'm afraid I get another errorsA:

./fix-flash.sh /usr/lib/firefox-3.6/firefox
./fix-flash.sh: line 11: [: too many arguments
./fix-flash.sh: line 16: 0x080495a8 - 0x08049338
08049478: value too great for base (error token is "08049478")

No idea what might be wrong.

Thanks again,

Pablo

[promac (promac-redhat-bugs)]

You did not understand. What should be patched is the flash-plugin (libflashplayer.so), and not firefox.

I changed my .src.rpm to patch even the 32 bit version:

rpmbuild --rebuild flash-plugin-10.3-1.fc14.src.rpm

You should see it downloading the source from adobe and patching it.
After doing that, install the created rpm and restart firefox.

You should check using "about:plugins" in firefox address bar, whether it is really using the new version.

[fedora (fedora-redhat-bugs-1)]

(In reply to comment #175)
> I changed my .src.rpm to patch even the 32 bit version:
>
> rpmbuild --rebuild flash-plugin-10.3-1.fc14.src.rpm
>
> You should see it downloading the source from adobe and patching it.
> After doing that, install the created rpm and restart firefox.

Thanks, I rebuilt your source rpm and it downloaded and patched the flash-plugin.

But it didn't work.

Thanks anyway,

Pablo

[alexander.hunt2005 (alexander.hunt2005-redhat-bugs)]

Re: comment 175:
This method worked perfectly for me. (F14-x86_64 - Intel MacBook)

For other users like myself unfamiliar with rpmbuild (I had to do some googling to figure this part out) install rpmdevtools (inc deps) and chrpath (I could only find 0.13.6.fc12-x86_64, but it worked).

Thank You to all involved with figuring this one out, and an aside I didn't have to implement Linus' (et.al) patch, although Thank You to all of you as well, that was next...
Br,
alex

[aaron (aaron-redhat-bugs-1)]

Paulo's rpm didn't build for me because it was complaining about a missing build id. I uploaded an updated version of the rpm with the ld line changed to "ld -G --build-id mymemcpy.o -o mymemcpy.so" and it's working for me.

http://luchko.ca/~aaron/memcpy-1.1-1.fc14.src.rpm

[pinto.elia (pinto.elia-redhat-bugs)]

Just for fun, it's appropriate to say so it seems to me :=), I set up the GNU build system for mymemcpy, so you can do the usual ./configure make make install. Yes, it is overkill but it is "nice" hope. It is here

https://github.com/yersinia/junkcode/tree/master/linux/mymemcpy

and here the new (make distcheck) tarball

https://github.com/yersinia/junkcode/blob/master/linux/mymemcpy/mymemcpy-1.1.tar.gz

Regards

[smconvey (smconvey-redhat-bugs)]

I have no sound in firefox, but do have sound in other applications.

I tried to cut and paste the code from #38 to my command prompt (as root) but nothing seemed to run.

I also tried to copy the code from #94 into a file called ray.sh, made it executable, and issued the command "bash ray.sh" as root, but got the following error:

# bash ray.sh
objdump: 'a.out': No such file
objdump: Section '.plt' mentioned in a -j option, but not found in any input file
Can't find memcpy call in PLT

Please forgive my ignorance, but can someone please provide detailed steps on how to implement these fixes.

Thanks

[pinto.elia (pinto.elia-redhat-bugs)]

If you want something more simple download the tarball referenced on #179 and do

tar -zxvf mymemcpy-1.1.tar.gz

cd mymemcpy-1.1

./configure

make

make install (ad root or use sudo)

e follow the instruction on the README, changing the application after LD_PRELOAD if necessary.

Regards

[spoyarek (spoyarek-redhat-bugs)]

A slightly modified version of Linus' memcpy routine so that it builds for 32 bit as well:

1. Cut and paste this into a prompt:
---Cut below---
cat > $HOME/Downloads/linusmemcpy.c <<EOF
#include <sys/types.h>

void *memcpy(void *dst, const void *src, size_t size)
{
void *orig = dst;
#if __WORDSIZE == 64
asm volatile("rep ; movsq"
#else
asm volatile("rep ; movsl"
#endif
:"=D" (dst), "=S" (src)
:"0" (dst), "1" (src), "c" (size >> 3)
:"memory");
asm volatile("rep ; movsb"
:"=D" (dst), "=S" (src)
:"0" (dst), "1" (src), "c" (size & 7)
:"memory");
return orig;
}
EOF
cd $HOME/Downloads
gcc -O2 -c linusmemcpy.c
ld -G linusmemcpy.o -o linusmemcpy.so
---Stop cutting here---

2. Shutdown any running copies of your webbrowser.

3. Until a Adobe has fixed their Flash player, start your webbrowser as below:

For Firefox users:
LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /usr/bin/firefox &

For Google Chrome users:
LD_PRELOAD=$HOME/Downloads/linusmemcpy.so /opt/google/chrome/google-chrome &

[spoyarek (spoyarek-redhat-bugs)]

*** Bug 661385 has been marked as a duplicate of this bug. ***

[m.a.young (m.a.young-redhat-bugs)]

(In reply to comment #182)
> A slightly modified version of Linus' memcpy routine so that it builds for 32
> bit as well:

It builds for 32-bit but it doesn't work for me for 32-bit. I tried a simple test with ls which truncates filenames and ls -al which segfaults!

[zenczykowski (zenczykowski-redhat-bugs)]

Here, this one actually has a chance of working, still, totally untested.

---Cut below---
cat > $HOME/Downloads/linusmemcpy.c <<EOF
#include <sys/types.h>

void *memcpy(void *dst, const void *src, size_t size)
{
void *orig = dst;
#if __WORDSIZE == 64
asm volatile("rep ; movsq" :"=D" (dst), "=S" (src)
: "0" (dst), "1" (src), "c" (size >> 3) : "memory");
asm volatile("rep ; movsb" : "=D" (dst), "=S" (src)
: "0" (dst), "1" (src), "c" (size & 7) : "memory");
#else
asm volatile("rep ; movsl" :"=D" (dst), "=S" (src)
: "0" (dst), "1" (src), "c" (size >> 2) : "memory");
asm volatile("rep ; movsb" : "=D" (dst), "=S" (src)
: "0" (dst), "1" (src), "c" (size & 3) : "memory");
#endif
return orig;
}
EOF
cd $HOME/Downloads
gcc -O2 -c linusmemcpy.c
ld -G linusmemcpy.o -o linusmemcpy.so
---Stop cutting here---

[aaron (aaron-redhat-bugs-1)]

Just for people who don't want to build the rpm themselves I put up a pre-built version

http://luchko.ca/~aaron/memcpy-1.1-1.fc14.x86_64.rpm

just install and start firefox as

$ memcpy-preload.sh firefox

I've tested this on two machines and it fixes the problem for me.

[alexander.hunt2005 (alexander.hunt2005-redhat-bugs)]

RE: Comment 186.
Thanks Aaron, that was great timing. I just did a fresh install of F14-x86_64, so I've just installed your rpm, and it works perfectly for me too. I just had to use the full path since I'm testing the the beta Firefox. The path for my shortcut is: memcpy-preload.sh /usr/share/mozilla/firefox/firefox
Again Thanks and Best Regards

[fanisatt (fanisatt-redhat-bugs)]

Thanks a lot Aaron. Three machines included mine....
Now I can listen again to the music of hundreds/thousands of sites .....
I installed the memcpy as you said above.
Then I changed the command in the menu editor for the firefox and instead of : firefox %u , I put your command : memcpy-preload.sh firefox .
So I have the same feeling as previously. There is no need to run firefox in the konsole.
Really, I expected an official Fedora update to fix this major problem, even if Adobe has the responsibility for the bug.
Because the flash plugin is a necessary villain but a really small "tool" compared to the Fedora OS, that is a big "factory" with rich equipment and a lot of "deposits" full of tools.
It is not permitted for such a factory to raise the hands.......

[smconvey (smconvey-redhat-bugs)]

RE: Comment 186

Thanks. I downloaded your rpm and installed it as follows:

yum localinstall --nogpgcheck memcpy-1.1-1.fc14.x86_64.rpm

It wouldn't install without the "--nogpgcheck" flag

RE Comment 186 & Comment 187

I copied my firefox shortcut and changed the command to

memcpy-preload.sh /usr/share/mozilla/firefox/firefox

but it didn't work. So I tried

memcpy-preload.sh firefox

And it worked! However the sound is kind of quiet even with the speakers turned all the way up. Also, if I exit a youtube video during play, it makes a brief, but very loud hum.

[fanisatt (fanisatt-redhat-bugs)]

I got the official update of glibc today (Feb 9 2011) and I hoped that the problem with flash plugin might be solved. So I tried the command firefox %u but I was wrong..... The problem remains !!
Thanks again Aaron for your memcpy-preload.sh firefox.
Earth calls Fedora Planet. Is anybody out there ? Over .

[lsatenstein (lsatenstein-redhat-bugs)]

Up to date as of 2011Feb14, and the problem persists.

[christopher.fabritius (christopher.fabritius-redhat-bugs)]

I noticed the status is now assigned, but the fix (based on my understanding of the discussion above) appears to be a trivial rollback of a change to glibc.

Do you need additional triage information to fix this issue?

Confirming the issue on a current Fedora 14, flash-plugin-10.3.162.29-1.x86_64

[simon.lewis (simon.lewis-redhat-bugs)]

Please rollback changes to Glib - this is a servere bug on fedora fc14 x86_64 with intel hardware...

Also, the severity should be marked as "urgent" not medium - this is a real show stopper.

[awilliam (awilliam-redhat-bugs)]

a glitch with an unsupported (upstream) version of an unsupported (by us) third-party plugin does not qualify for any kind of 'urgent' status by any stretch of the imagination, I'm afraid.

running the 64-bit Flash plugin is just generally a bad idea, because they never keep it up to date with the 32-bit one, so it's always vulnerable to several known serious security issues. And 'known serious security issues in Flash' is really not something you want to be exposing your computer to. Just run the 32-bit version, really, you'll be doing yourself a favour.

[pigetak178 (pigetak178-redhat-bugs)]

I give up waiting for a fix and will just install the 32 bit wrapped one. This does not make 64 bit Fedora a standout product. You can sit in the ivory tower all you want, but you end up looking silly.

[alexander.hunt2005 (alexander.hunt2005-redhat-bugs)]

From an end-user perspective, and in my humble opinion:
I refuse to install anything that pulls in i686 dependencies to my x86_64 system and for that reason will not install software such as Skype and any of the Google for Linux software, and that includes flash wrappers. If I wanted a mixed up UNIX OS I would just use Snow-Leopard on my MacBook and save myself a ton of work making Linux work as I want my OS to work.
I understand that having compatibility to the new mini-processors is important to somebody who uses mini-machines, but really, would it be that difficult to make a version of glib for those and another one for the mainstream processors? What I mean is make a note in the release notes of the current version for which mini-processors it is supporting. At the same time, revert the glib changes, re-package it, and make a note in the release notes for which processors it is supporting. Problem solved. If someone makes an error in installation it is easy to revert to the other version.
I have read through every comment in this bug issue several times since it was started and have noticed some interesting things: Redhat Fedora developers defending their product, saying they aren't interested how many users switch to different flavours of linux, blaming a 3rd party vendors product for all the problems, and being somewhat bull-headed about changing what has been done.
So what happens when some other 3rd party company starts doing what Adobe has done that causes(?) problems with functionality in the OS? There will be another bugzilla report about that one and a long argument about who is to blame, who should fix what and a small group of end-users and end-user developers trying to find a workaround so that the software works as it should. I know for a fact that all software will have bugs; that is a reality of computing. Passing blame and being bull-headed about your position doesn't help anyone, and leaving workarounds up to end-users isn't very professional.
One last point to Redhat: Yes it is nice of you to provide a free OS to the world and spend lots of money and your paid developers' time working on it, but the fact is, you also get a great number of people testing your cutting edge software for free and reporting back, and working with your employees and other un-paid developers to fix the issues before you port the software over to your paid version, which drastically reduces the amount of support time and time spent fixing glitches for your paying customers which makes you look really good to them, so please don't underestimate the value of Fedora users staying with Fedora as an OS. I have used Redhat products as an OS since there was only one fast way to get it; buy the book with the CD in it (the other option being spending a week on dial-up downloading it), and I don't want to change now or in the future, so please, just a little respect for what you get out of the end-users would be appreciated. Granted, you are a company, but also; all of us are a community with pride in making Fedora the best OS out there. Let us not forget that. BTW, this is not a rant, just my opinion. Thanks for reading.

[belegdol (belegdol-redhat-bugs)]

Created attachment 480017
Linus' workaround

Come on guys, please stop whining. This does not add any real value and only makes *working* workarounds harder to find. I personally use the one Linus posted in comment 38 - the cat commands posted in this bug only work if ~/Downloads exists, which is not the case if you have localised XDG folders.
Just grab the file I attached, compile it, and then make a script in your ~/bin that adds it to LD_PRELOAD (I'll attach mine for convenience). Then you can forget that this problem ever existed until Adobe fix their bug.

[belegdol (belegdol-redhat-bugs)]

Created attachment 480018
example launcher script

[torvalds (torvalds-redhat-bugs)]

Don't use my workaround: it was a stupid hack to test the bug, and show that "always copy upwards" works better than the crap that is in glibc now.

A much better workaround is likely to just implement memcpy() as memmove() (you can replace the inline asm by that in my preload example if you want to). Once memcpy() isn't small and trivial any more, that's just the right thing to do.

The fact that the glibc people don't do that, and that this hasn't been elevated despite clearly being a big usability problem (normal users SHOULD NOT HAVE TO google bugzillas and play with LD_PRELOAD to have a working system), is just sad.

Quite frankly, there is no reason for the current memcpy() mess. There is no _technical_ reason for it, and there is certainly no usability reason for it. Why the Fedora people don't just fix it, I don't understand. It's a shame and a disgrace.

The fact that Adobe does something that isn't technically right is no excuse for having a sub-par crap memcpy() implementation.

And how does one raise the priority for a bug in bugzilla, or get it re-assigned to somebody who cares?

[m.a.young (m.a.young-redhat-bugs)]

(In reply to comment #199)
> And how does one raise the priority for a bug in bugzilla, or get it
> re-assigned to somebody who cares?

You can complain to FESCO https://fedoraproject.org/wiki/FESCO though unfortunately this has been tried already, see https://fedorahosted.org/fesco/ticket/501 .

[awilliam (awilliam-redhat-bugs)]

This is a bug reporting system, not a discussion forum.

Linus: this is Fedora Bugzilla, not upstream glibc bugzilla; if this is a significant issue in upstream glibc it'd be best to raise it through the appropriate upstream channels. In talking about this specific report, all I can go on is the practical impact on immediate Fedora issues.

[awilliam (awilliam-redhat-bugs)]

upstream glibc bugzilla: http://sources.redhat.com/bugzilla/

[awilliam (awilliam-redhat-bugs)]

btw, priority field is by Fedora policy reserved to maintainers for the purpose of organizing bugs however they want. It has no intrinsic meaning; there's no policy requiring a certain response time to high priority bugs or anything like that. It doesn't really make any sense to mandate a project-wide policy for the Priority field since developers are entirely free to ignore it if they wish.

I don't think the glibc maintainers actually use the priority field to organize their bugs, so changing the priority field on this bug would achieve exactly nothing.

[robin.bowes (robin.bowes-redhat-bugs)]

<sigh> And there's a beautiful example of the disconnect between the Redhat devs and the real world.

Somebody (actually, not just "somebody" but the guy who MADE IT POSSIBLE FOR YOU GUYS TO HAVE A JOB AT ALL) asks the question "And how does one raise the priority for a bug in bugzilla, or get it re-assigned to somebody who cares?" and you respond by talking about a field in a bug reporting system.

C'mon guys, get real. Fix it. Patch it. Whatever. But get your heads out of your arses and do something!

R.

[smconvey (smconvey-redhat-bugs)]

I believe the following link is the correct place to report a bug in glibc:

http://cygwin.com/bugzilla/

However, I'm not knowledgeable enough to properly report this bug there. Could someone please post this bug there and then post here to let us know what the bug number is so we can follow.

Thanks.

[awilliam (awilliam-redhat-bugs)]

robin: linus asked how you raise the priority for a bug in Fedora bugzilla. The answer is, you don't, for the reasons I explained: given how the Fedora project is set up, there is no single simple mechanism for doing so, as we (intentionally) don't have any authority which can, in the usual course of events, wield a big stick and say This Bug Is High Priority. your not liking the answer does not make it not the answer.

The Fedora project trusts its glibc maintainers to maintain glibc correctly, in general, so they are trusted to prioritize their workload accordingly. should someone have a problem with this they can, as Michael Young pointed out, raise it with FESCo, but that's hardly a regular bug priority assignment system.

[charlieb-fedora-bugzilla (charlieb-fedora-bugzilla-redhat-bugs)]

> The Fedora project trusts its glibc maintainers to maintain glibc correctly,

Fools. They can't be trusted - the evidence is before you. You can fix it - for Fedora. The fact that glibc project doesn't is no excuse for you not to.

[whizzman (whizzman-redhat-bugs)]

I'm pulling the "security card".

By allowing the memcpy/memmv thing to happen, you are introducing a lot of potential security hazards. You can say that the hazard is introduced by Adobe in Flash, but in fact there have already been several related bugs found in Fedora's own repository of packages. It's just a symptom of an underlying problem that is much bigger and deeper. You don't want someone to find code that will break a system remotely, or even do a (remote) privilege elevation because he can overwrite parts of memory with bits he likes to be there.

You can't just say "it's up to the package maintainers to fix it". There's SElinux, random start addresses, non executable stack, all large pieces of code in place, just to mitigate this sort of bug turning nasty. By allowing the code to run unchecked, while there are so many known, possible dangerous examples of bad code around, you are compromising security. These packages have all been put in place just to avoid user space code to be abused. I think that is more than adequate proof that you need to take measures to avoid other persons bugs to cause harm.

I know that at this stage it's academical to say it's a security hazard, but given time, enough typewriters and an adequate supply of monkeys, it will be real. History has proven that much. Even all of the above mentioned frameworks have been broken, and I have no doubt some smart and determined person will find a use for this as well. If this behavior is going to be part of glibc, a check to avoid resulting bugs, and/or mitigation for exploiting this should be in place, just like the above mentioned frameworks do.

I propose reversing the memcpy/memmv change for the time being, as a security measure. After that, make sure that the effects of the bugs in other code depending on it are mitigated or removed, before re-introducing it. Maybe by introducing a warning/error in gcc?

[mail2benny (mail2benny-redhat-bugs)]

Last resort:
Since the guys at glibc are so stubborn and cannot admit they made a mistake... Cant we repackage the newest glibc without the crappy memcpy()? (At least a (temporary) patch) C'mon guys...

[alexander.hunt2005 (alexander.hunt2005-redhat-bugs)]

I agree with Benny and Homme Bitter's last paragraph (+Thanks for the security angle)
According to: Michael Young, Comment 16:
The sound is good with F13 glibc (2.12.1-4) on F14. I
have been hunting through glibc versions. The sound was good with
glibc-2.12.90-3 but first started sounding corrupted with glibc-2.12.90-4.

So when it was changed and the problems started we know.
Even if Fedora doesn't want to do it, would it be possible for somebody who knows how to do it take the newest version of glibc, fix it, and post it somewhere that's not on a Fedora server? Or, maybe some group of people should branch it and put it on rpmfusion or something...
As an aside,this was an interesting read:
https://fedorahosted.org/fesco/ticket/501
It would be interesting to know why it was last commented as "fixed".It would probably be more appropriately marked as "won't fix" lol...and there has been no further comment for almost 3 months.

[promac (promac-redhat-bugs)]

I agree it is complicated to support a different glibc from the one available upstream. In case of a 3rd party repo providing a parallel glibc, who is supposed to be responsible for updating it in case of new bug fixes? This is an endless work, which nobody will want to be responsible for.

In my opinion, for those not wanting to use the 32 bit version, the best fix is using a flash plugin that replaces memcpys for memmoves.

This is a no source rpm, which downloads the source from adobe and changes the binary:

http://people.atrpms.net/~pcavalcanti/srpms/flash-plugin-10.3-1.fc14.nosrc.rpm

I am more interested in this issue from a performance point of view than
from its effect on the flash plugin. If the new version is really slower that the previous one, well, then there is no excuse for not reverting the code.

[alexander.hunt2005 (alexander.hunt2005-redhat-bugs)]

Hopefully this will be the last I have to say about this issue, except for "Thank You" to the people who help get the problem fixed.
First: Adobe is working on a fix for the problem (ref: Markus, comment 118). Perhaps if we ask nicely, Markus would be willing to email his contact at Adobe and ask for an ETA on the new Flash version (I believe the last on that was it was going to QA). Please Markus? :)
Second: the adaptation of Linus' (et al) test-code provided by Aaron (in comment 186), in combination with the rework of flash provided by Paulo (now in comment 211, and a Thank you to you) works on every flash enabled site I have visited (neither of them alone work everywhere for me), and from a strictly end-user point of view, they are both easy to implement. Disclaimer; I do not know the security issues, speed factor, or any other implications of using both workarounds together. My system doesn't seem to have any problems with it, but your mileage may vary.
Third; If Adobe is going to take any length of time, my vote would be for someone or a group of people to rework glibc for the time-being (I would do it myself if I had any clue where to start), and hope that there are no bug-fixes required before Adobe puts out a revised version of flash.
Paulo is correct that it probably makes no sense to branch glibc (although I have to disagree that nobody would maintain it; if that was the case Linux would not be where it is today. Linus' creation and the way he did it proves people will work on something they believe in. Thank you very much Linus, and I'm not bashing you about that Paulo, just disagreeing). Regardless, anyone can easily switch back to the mainstream version of glibc when Adobe fixes flash and it works properly for them. I realize that this doesn't address some of the other issues brought up about the coding quality, security, speed (ie. processor cycles used for different functions), and the g-streamer plugin with the same problem, etc, but I am not knowledgeable enough about those issues to speak about them.
Thanks for reading; I pass the torch and am now going to get some sleep. :)

[seg (seg-redhat-bugs)]

Seriously people, this is all about one piece of proprietary software, the 64-bit Flash plugin. A piece of 'preview' software about which Adobe themselves say, "We do not recommended that this release be used on production systems or for any mission-critical work."

http://labs.adobe.com/downloads/flashplayer10_square.html

This is a textbook case of *exactly* what Fedora does not support. Fedora is a distribution with core values and a mission. Fedora is *not* about getting market share at any cost.

If you don't like it, you're simply using the wrong distribution.

The 32-bit flash plugin works fine. Y'all are lucky we tacitly support the 32-bit Flash plugin as much as we do.

Though admittedly we seem to be failing to communicate this point to new users. Looking at http://fedoraproject.org/en/about-fedora and what it links to, is nothing but a lot of fluffy words and abstract concepts, and I can see how no one could possibly understand the concrete practical aspects of it. The closest I can find is at the bottom of http://fedoraproject.org/wiki/Objectives

"The Fedora Project is not interested in having its distribution be a platform for proprietary or patent encumbered components. While we do not purposely make installation of such components more difficult, we also do not allow our schedule or processes to be driven by theirs."

Which boils down to "Workarounds for proprietary software are included purely at the package maintainer's discretion and are most likely going to be rejected".

[whizzman (whizzman-redhat-bugs)]

It's NOT about the flash plugin, it's about a change in how a glibc call is handled. This breaks an unknown amount of packages and introduces erratic an possibly insecure behavior for an unknown number of Fedora's own applications. It just happens to hit the common user base the hardest on the 64 bit flash plugin, but the effect on stability and security of the entire distribution is much bigger than just the plugin.

[seg (seg-redhat-bugs)]

This is not a change that Fedora made. This is a change that went through all the normal upstream channels that *any* change to glibc goes through. All users of glibc are effected. And yes, this is one of the most fundamental parts of the entire system, copying memory. It effects almost every GNU/Linux user in the entire world.

If it broke things, it would turn up quickly.

If you think this change is untested, you don't understand how open source works.

So far, the only proven breakage is the 64-bit flash plugin.

In short, provide proof, or its just a lot of talk.

(Disclaimer: I am NOT in any way a glibc maintainer)

[tmraz (tmraz-redhat-bugs)]

Unfortunately the breakage might be very subtle - even normally unnoticeable in some packages. But even in this case it might be very well exploitable by malicious attacker. Of course you can always dismiss it by saying that the affected packages are buggy in using memcpy incorrectly - sure. But this does not make our (Fedora) users of these packages less prone to the attacks. You cannot simply say that Fedora (non-third party) packages are unaffected because the insecure use of memcpy cannot be surely detected in other way than by a careful code review or runtime checks (with abort).

[jcm (jcm-redhat-bugs)]

Similarly, just because something was "tested" in the artificial world of developers running purely Open Source components doesn't mean that users (like me) don't want to run a flash plugin, or other non-Open Source software on their systems. There are plenty of things I do for electronic engineering on weekends for which there is no Open Source alternative, so the answer is not always to assume that proprietary stuff is "just wrong".

Jon.

[seg (seg-redhat-bugs)]

I never said anything about proprietary stuff being wrong. You're projecting.

You speak as if this change to glibc didn't undergo testing by Intel before they submitted it to glibc. Then go through whatever review and testing the glibc project has. Then go through a full Fedora rawhide/beta/testing cycle. And then a Fedora final release. It has not had any special treatment. It has gone through the same testing any change to glibc gets.

These implications that this change to glibc is in any way untested are just patently absurd.

Lets see the bug reports, or you're just spewing FUD about your own product.

(And one again its being glossed over the fact that the 32-bit flash plugin works fine. This is a problem only in the *explicitly* unsupported by Adobe 64-bit *PREVIEW* flash plugin. No one is stopping anyone from having Flash. If you're truly hung up on a geek fetish for some kind of "64-bit purity", a great variety of workarounds have already been established. Isn't open source great? :)

[simon.lewis (simon.lewis-redhat-bugs)]

(In reply to comment #218)

Lets get back to basic facts here...

glibc is a security hazard and should be fixed without any further delay, for example by implementing memcpy() as memmove()...

[hdfssk (hdfssk-redhat-bugs)]

It actually wasn't a flash player problem that led me to this bug; many of my mp3s started playing with heavy bubbling-sounding interference right after I upgraded to F14. It took a decent while for me to find this bug, and was a good deal longer before comment #164 (https://bugzilla.redhat.com/show_bug.cgi?id=638477#c164) described the workaround... but it's *not* just one piece of software that had this problem.

I hear Adam's point in comment #201 about this not being a discussion forum - I came here today bcs the latest conversation's blowing up my inbox - but at the same time, *where* should someone discuss this sort of thing? The message I'm taking away from all this is "This isn't a problem; why are you all saying it is? Trust us, we Know about these things. Shush!" Well, it pretty plainly is a problem for some folks; what's served by marginalizing their concerns? ...and what does it say to average Fedora users when the guy who built the Linux kernel can't get *his* concerns heard? It sure doesn't encourage me to participate in the Fedora community, or try to volunteer; it seems like a huge waste of time. I’d like to believe that concerns about security will lead to something being done, but... we’ll see.

As for comment #213's "If you don't like it, you're simply using the wrong distribution" - that's a crap attitude. This discussion's got to be frustrating for all involved, but let's please try to treat each with decency and respect, yes?

[awilliam (awilliam-redhat-bugs)]

you can discuss it on an appropriate mailing list, or forum. we have a lot of them.

Listening to people is not the same as doing exactly what they demand. The Fedora project has long-standing values relating to working upstream and prioritizing software freedom; if you don't share those it really *may* be the case that you're not using the right distribution. There are others which place a higher value on accommodating proprietary software and carrying downstream patches.

[torvalds (torvalds-redhat-bugs)]

(In reply to comment #221)
>
> There are others which place a higher value on accommodating proprietary
> software and carrying downstream patches.

Why the hell do people like you continue to think this is about "proprietary software"?

This is about "helping users". It has absolutely _nothing_ to do with proprietary or not, and is about the fact that binary compatibility matters.

It's also about doing a good job.

Breaking existing binaries with a shared library update IS A BAD THING. How hard can that be to understand? If you break binary compatibility, you need to update the library major version number.

And there really isn't any valid technical reason for doing a bad job at memcpy.

What is annoying is how people have turned this "glibc broke existing binaries" into some kind of "free software vs proprietary" crap. That's not the point. I know from personal involvement in git that the whole "oops, we used memcpy where we _should_ have used memmove" is a common bug. Bugs happen. The binary may even have been really well tested, but it was tested with a library that consistently did things some way.

Now glibc does random things. The direction of the copy will seemingly depend on things like random alignment issue, rather than any repeatable thing, so just access patterns etc make it do different things for no good reason.

I repeat: "for no good reason". There's no REASON for glibc to break things.

So stop the whole "proprietaty software" crap. It's about USERS. And it's about Quality-of-implementation.

In the kernel, we have very strict rules of "we don't break binary compatibility unless we _have_ to". It doesn't matter if it's a result of a bug in user space or not ("you shouldn't have been doing that") we revert patches that break things. Sure, occasionally we have major reasons why we can't see it as that kind of absolute rule (security bugs that simply require visible changes, or major re-architecting of some area that makes it impossible to support some old API), but they really need to be major reasons.

Why? Because _users_ are the only thing that makes software useful. Software isn't useful on its own. You cannot say "this is the right thing to do" unless you take users into account.

And no, "there is a workaround" is not good enough, unless that workaround is then automatic from the distribution. Most users that hit this issue will never ever see this bugzilla. They will just say "Fedora is buggy".

And they'd be right.

I'm disappointed. Stop the idiotic parroting of "proprietary app". Think about what users do, and think about all the random binaries people run.

[awilliam (awilliam-redhat-bugs)]

again, discussion forum, me, getting sucked into it. let's stop now. I'm just trying to explain the values in play here and why certain things happen that may appear odd. it's not my decision to take, I'm just trying to keep order in the bug report.

I still haven't seen anyone report this to glibc upstream, btw. that still seems like an obvious next step to me. but what needs to happen next on this report is a Fedora glibc maintainer to explain what's going to happen and change the bug status appropriately.

[sergio (sergio-redhat-bugs-1)]

Hi,
I'm off, because this discussion will not end until Adode fix the problem, since this is not a bug on glibc, this bug should be close.
See comments #164 and the solution on #94

You have a forum in Adobe
http://forums.adobe.com/community/labs/flashplayer10/square64bit?view=discussions&start=0
and https://bugs.adobe.com/jira/browse/FP-5739
which have many bug reports that Adobe doesn't fix and have at least have 2 months.

[charlieb-fedora-bugzilla (charlieb-fedora-bugzilla-redhat-bugs)]

> I still haven't seen anyone report this to glibc upstream, btw. that still
> seems like an obvious next step to me.

I would think Fedora maintainers would be quite capable of doing that. Fix glibc to help your users. Then explain to glibc maintainers exactly why you did so (e.g. you could quote Linus). Stop passing the buck (and stop blaming Adobe, and glibc), and stop treating users as though they don't matter.

[Torvalds (torvalds)]

Created attachment 5264
Example patch to give the basic idea

I realize that it's technically "undefined", but the behavior has changed, and in the process broken existing binaries. It's a common bug to use memcpy() instead of memmove(), and the traditional behavior of "copy upwards" means that that bug can go unnoticed for a *long* time if the memory move moves things downwards.

The change was introduced in commit 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba ("Improve 64bit memcpy/memmove for Atom, Core 2 and Core i7"), which was part of the 2.13 release.

As a result, upgrading from Fedora-13 to Fedora-14 caused applications like flash to fail. But it's a bug that has been reported for other applications too (and it's a bug that I've personally introduced in 'git' too - happily, people had run things like valgrind, so I don't know of any _current_ cases of it).

And there is absolutely _zero_ reason to not handle overlapping areas correctly. The "undefined behavior" is due to historical implementation issues, not because it's better than just doing the right thing.

And now applications will randomly do different things depending on the phase of the moon (technically, depending on which CPU they have and what particular version of memcpy() glibc happens to choose).

So from a pure Quality-of-Implementation standpoint, just make glibc implement memcpy() as memmove(), if you don't want to re-instate the traditional behavior that binaries have at least been tested with. Don't break random existing binaries just because the glibc version changed, and they had never been tested with the new random behavior!

I'm attaching an EXAMPLE patch against the current glibc git tree: it just tries to get rid of the unnecessary differences between memcpy and memmove for the normal ssse3 case. The approach is simple:

 - small copies (less than 80 bytes) have hand-coded optimized code that gets called through a jump table. Those cases already handle overlapping areas correctly (simply because they do all loads up-front, and stores at the end), and they are used for memmove() as-is.

   So change the memcpy() function to test for the small case first, since that's the one that can be latency critical.

 - once we're talking about bigger memcpy() cases, the extra couple of cycles to check "which direction should I copy" are totally immaterial, and having two different versions of basically the same code is just silly and is quite likely to cost more than (in I$ and page fault overhead) than just doing it in the same code. So just remove all the USE_AS_MEMMOVE games.

I haven't actually tested the patch, since building glibc is black magic and the simple "just alias __memmove_ssse3 to __memcpy_sse3" thing didn't work for me and resulted in linker errors. There's probably some simple (but subtle) magic reason for that, that I simply don't know about.

So take the patch as a "hey, doing it this way should be simpler and avoid the problem" rather than "apply this patch as-is". The ssse3-back case (which prefers backwards copies) needs similar treatment, I'll happily do that and test it if people just let me know that it's worth my time (and tell me what the black...

[Torvalds (torvalds)]

Btw, this has hit quite a lot of people. It's Fedora

  https://bugzilla.redhat.com/show_bug.cgi?id=638477

and there are examples of having other things than just flash break (like old gstreamer plugins etc)

[Hjl-tools (hjl-tools)]

Although the current memcpy in glibc follows the spec,
some applications call memcpy with overlapping destination
and source.

I think we should help those applications without punishing
the correctly written applications. We can check an environment
variable for IFUNC, like LD_BIND_IFUNC_MEMCPY_TO_MEMMOVE.
If it is set, IFUNC memcpy will return memmove instead
of memcpy. I can prepare a patch to implement it if we
should do it.

[Torvalds (torvalds)]

So is there any real reason to believe that memmove() can't just be as fast as memcpy?

Seriously. That's what it all boils down to. Why have a separate memcpy() at all, when it clearly is correct - and nice to people - to always just implement it as a memmove(). And I really don't see the downside. It's not like it's going to be slower.

People who want to check whether their application is portable can use valgrind, the same way you have to check for portability issues in other areas (eg the extra glibc specific printf formats etc - they just "work", but they certainly aren't portable).

So why not just be nice.

If anything, from a "be nice" standpoint, it would perhaps be good to have a "debug mode", that would actually _warn_ - or even assert - about overlapping memcpy(). That obviously shouldn't be the default (since that only helps developers), but it would be along the same lines of the nice malloc debugging help that glibc can give.

IOW, I think this is an area where glibc can be _better_ than what is required of it.

[simon.lewis (simon.lewis-redhat-bugs)]

glibc allows other programs to overwrite adjacent memory - this is a security hazard and must be fixed in glibc...

[patrys (patrys-redhat-bugs)]

Computers in general allow people to overwrite memory, you should all get rid of your computers as they are a security threat. Stop blaming glibc maintainers with the faults of others. Stop blaming Fedora. And, for the love of your chosen deity, stop filling my mail account with junk.

Every reply you post reaches at least 120 people who are not Fedora developers. This is not a popularity contest. This is not democracy. You cannot force the devs to fork glibc and maintain the patches for the rest of their lives. If you want this changed, go file bugs with glibc and convince drepper to either pull that change or make it depend on the target CPU (let people explicitly target machines where the new memcpy does make things faster).

[Drepper-fsp (drepper-fsp)]

The existence of code written by people who should never have been allowed to touch a keyboard cannot be allowed to prevent a correct implementation. If there is a large bod of code out there we can work around the issue for that.

We can have the existing memcpy@GLIBC_2.2.5 implementation work around the issue by avoiding the backward copying code. A new memcpy@GLIBC_2.14 could use the code currently in use.

Whether the current, new memcpy is only slightly faster than one mimicking memmove is really not that important. There are going to be more and different implementations in the future and they shouldn't be prevented from being used because of buggy programs. We should be happy to have this code here and now.

With this proposed implementation old code remains in working order until those lousy programmers use a newer platform and then they will experience the problems themselves and will fix them before releasing their code.

I'm happy to entertain a patch to this effect.

[Jakub Jelinek (jakub-redhat)]

If we go that route (symbol versioning memcpy), then wouldn't it be better to just alias the old memcpy@GLIBC_2.2.5 to memmove and have the new memcpy@@GLIBC_2.14 be the only memcpy implementation? Having two sets of memcpy implementations (especially when we have many memcpy implementations on x86_64 and i?86 selectable via STT_GNU_IFUNC), even if the workaroundish one is placed in compat .text subsections, would waste too much code section in libc.so.6.

[Hjl-tools (hjl-tools)]

(In reply to comment #5)
> If we go that route (symbol versioning memcpy), then wouldn't it be better to
> just alias the old memcpy@GLIBC_2.2.5 to memmove and have the new
> memcpy@@GLIBC_2.14 be the only memcpy implementation? Having two sets of memcpy

I like this idea.

[Drepper-fsp (drepper-fsp)]

(In reply to comment #5)
> If we go that route (symbol versioning memcpy), then wouldn't it be better to
> just alias the old memcpy@GLIBC_2.2.5 to memmove and have the new
> memcpy@@GLIBC_2.14 be the only memcpy implementation?

That's what I have in mind.

[richmattes (richmattes-redhat-bugs)]

(In reply to comment #223)
> I still haven't seen anyone report this to glibc upstream, btw. that still
> seems like an obvious next step to me. but what needs to happen next on this
> report is a Fedora glibc maintainer to explain what's going to happen and
> change the bug status appropriately.

Looks like it's at:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=12518

[awilliam (awilliam-redhat-bugs)]

guh. our external tracker list sucks giant....lollipops.

[felipe.contreras (felipe.contreras-redhat-bugs)]

Why not name this "regression in glibc causes memory corruption"? That's actually what is happening, and the solution is to either:

 1) Fix glibc so the old behavior is not broken (mapping memcpy to memmove)
 2) Downgrade glibc until it's fixed upstream

The fact that this regression has only been seen on proprietary code is irrelevant, it might be happening all over the place.

[Felipe Contreras (felipec)]

"Buggy" code can be linked to the new memcpy@@GLIBC_2.14 by just recompiling, no? That doesn't really solve anything.

Sure, code should use memcpy correctly, and if glibc has a compelling reason to break these programs, it should. As Ulrich mentions in comment #4 "There are going to be more and different implementations in the future and they shouldn't be prevented from being used because of buggy programs."

But _today_ that's not the case. Today, the regression can be fixed easily with a patch like what Linus is proposing, and there will be no *downside* whatsoever.

How about glibc breaks the behavior _only_ when there's an *upside* to breaking it?

[awilliam (awilliam-redhat-bugs)]

"The fact that this regression has only been seen on proprietary code is
irrelevant, it might be happening all over the place."

So might the Giant Flying Spaghetti Monster. We don't work on the basis of what might, theoretically, be happening. Provide concrete examples or just stop extending this report to no good reason.

I see actual useful discussion between people who know what the hell they're doing happening in the upstream bug; I'm all in favour of simply following whatever is decided there in the downstream package.

[felipe.contreras (felipe.contreras-redhat-bugs)]

(In reply to comment #231)
> So might the Giant Flying Spaghetti Monster. We don't work on the basis of what
> might, theoretically, be happening. Provide concrete examples or just stop
> extending this report to no good reason.
>
> I see actual useful discussion between people who know what the hell they're
> doing happening in the upstream bug; I'm all in favour of simply following
> whatever is decided there in the downstream package.

See the title of the upstream bug:
"memcpy acts randomly (and differently) with overlapping areas"

_That_ is what is happening, it's not hypothetical, there's 125 people affected by this issue and following it, and upstream has accepted that indeed it's an issue.

How about we turn the papers; _you_ come up with proof that all the memcpy's happening in all the binaries in all packages of Fedora are correct and unaffected by this change, and thus there's no security issue. Can you really do that?

[jvillalo (jvillalo-redhat-bugs)]

(In reply to comment #232)
> (In reply to comment #231)
> > So might the Giant Flying Spaghetti Monster. We don't work on the basis of what
> > might, theoretically, be happening. Provide concrete examples or just stop
> > extending this report to no good reason.
> >
> > I see actual useful discussion between people who know what the hell they're
> > doing happening in the upstream bug; I'm all in favour of simply following
> > whatever is decided there in the downstream package.
>
> See the title of the upstream bug:
> "memcpy acts randomly (and differently) with overlapping areas"
>
> _That_ is what is happening, it's not hypothetical, there's 125 people affected
> by this issue and following it, and upstream has accepted that indeed it's an
> issue.
>
> How about we turn the papers; _you_ come up with proof that all the memcpy's
> happening in all the binaries in all packages of Fedora are correct and
> unaffected by this change, and thus there's no security issue. Can you really
> do that?

To go even more off tangent. That is the kind of logic used to say there is a god. Since you can't prove there is a god there must be a god. And god could be whichever diety you like (Flying Spaghetti Monster, Thor, Isis, etc). Basically your request is realistically impossible.

[milan.kerslager (milan.kerslager-redhat-bugs)]

As written above this glibc regression hits nearly all packages not just Flash.
So the assumption not to fix glibc because Flash is closed source is plain wrong.

[awilliam (awilliam-redhat-bugs)]

Please, please, please stop arguing pointlessly in circles.

[milan.kerslager (milan.kerslager-redhat-bugs)]

Yes. So please do not argue to Flash when the problem is in Glibc and do not stand with the position not to fix Glibc because Flash is closed source (this is The Circle). The Flash is not worth to talk about. The problem is a function in Glibc - no matter that almost everybody making mistakes using similar Glibc calls in wrong context (and they are pointlessly implemented with different broken ways) no matter if this is in closed or open source code or product.

[seg (seg-redhat-bugs)]

You glibc maintainers have been educated evil! You deny the simultaneous 4-cornered 64-bit Flash Cube! We must not let this flashlessness stand! Your ignorance of the Harmonic Flash is demonic!

64-bit Cubic Flash debunks 32-bit AS WITCHCRAFT!

[felipe.contreras (felipe.contreras-redhat-bugs)]

(In reply to comment #235)
> Please, please, please stop arguing pointlessly in circles.

From what I can see *you* are the only one doing that... Everybody else has agreed it's a real issue.

[Drepper-fsp (drepper-fsp)]

(In reply to comment #8)
> "Buggy" code can be linked to the new memcpy@@GLIBC_2.14 by just recompiling,
> no? That doesn't really solve anything.

It solves everything. If you just relink without retesting you're an idiot and acting irresponsible.

[Torvalds (torvalds)]

(In reply to comment #9)
>
> It solves everything. If you just relink without retesting you're an idiot and
> acting irresponsible.

It does solve a lot, and at least fixes the "you broke stuff that used to work" issue.

However, I still don't understand why you guys can't just admit that you might as well just do memmove() and be done with it. It's not slower. And the excuse that "you'll have more implementations in the future" is just an even stronger reason to do that.

To make this very clear: your new "and improved" memcpy() ACTS DIFFERENTLY ON DIFFERENT MACHINES. That means that all that testing that was done by the developer at link-time is ALMOST TOTALLY WORTHLESS, because what was tested wasn't necessarily at all what the user sees.

I really don't understand why you can't admit that random behavior like that by a very fundamental core library routine is actually a real problem.

And there really isn't any upside. The optimized routines up to 80 bytes are the same (in fact, my patch should speed them up by a few cycles), and anything bigger than that will not notice the extra couple of cycles to check for overlap.

So while I agree that it's a fix to the immediate problem to just say "don't screw up for existing binaries", I do NOT understand why the glibc people then apparently think it's fine to be stupid for new binaries.

[Felipe Contreras (felipec)]

(In reply to comment #9)
> (In reply to comment #8)
> > "Buggy" code can be linked to the new memcpy@@GLIBC_2.14 by just recompiling,
> > no? That doesn't really solve anything.
>
> It solves everything. If you just relink without retesting you're an idiot and
> acting irresponsible.

You cannot test every possible code-path.

[awilliam (awilliam-redhat-bugs)]

stating your argument over and over again is exactly what I mean by 'arguing in circles'.

[Oliver-henshaw (oliver-henshaw)]

The thread starting at http://lwn.net/Articles/414496/ may be instructive on how this can cause problems despite the good(-ish) intentions of the developer. In short, squashfs used memcpy with data that was known not to overlap but later changes invalidated this assumption.

[debaditya (debaditya-redhat-bugs)]

I tried both Magnus's (#55) and Ray Strode's (#94) fix. Both of them fix the issue of choppy sound in flash sites.

I just tested the amazon music preview site in firefox, after the song played nicely, keeping firefox open, I tried to play some music in clementine, mplayer or just gnome music preview. All of them failed to produce any sound. I needed to close firefox to be able to hear music from hard drive.

Somehow, the fix in firefox is blocking the soundcard access by other applications.

Any clue?

[kuznetsovvv (kuznetsovvv-redhat-bugs)]

@Deb Mukherjee

I met such behaviour of the audio subsystem when I removed all pulseaudio-related packages :) Please, check if you have pulseaudio in your system.

At this moment the following packages are installed in my one:

pulseaudio-0.9.21-7.fc14.x86_64
pulseaudio-libs-0.9.21-7.fc14.x86_64
pulseaudio-libs-0.9.21-7.fc14.i686
pulseaudio-libs-zeroconf-0.9.21-7.fc14.x86_64
pulseaudio-libs-glib2-0.9.21-7.fc14.x86_64
pulseaudio-libs-glib2-0.9.21-7.fc14.i686
pulseaudio-module-gconf-0.9.21-7.fc14.x86_64
pulseaudio-module-x11-0.9.21-7.fc14.x86_64
pulseaudio-module-zeroconf-0.9.21-7.fc14.x86_64
pulseaudio-utils-0.9.21-7.fc14.x86_64
alsa-plugins-pulseaudio-1.0.22-1.fc13.x86_64

Please, note the issue does not caused by the issue from this report. If you are unable to fix the issue, you can to search the solution on the http://www.fedoraforum.org/ or create the new thread there. I believe the fedora comunity will help you.

Thank you.

[debaditya (debaditya-redhat-bugs)]

@ Kuznetsov Vyacheslav

Thanks for your help.

<quote> Please, note the issue does not caused by the issue from this report.<\quote>
I am not sure the two issues are separate. I did not have the sound card blocking thing before trying LD_PRELOAD. I have all pulseaudio modules you have listed- and the problem started after I tried #55 fix.

[brentrbrian (brentrbrian-redhat-bugs)]

Two systems, F14, x86=64, all updates applied. This system has problem, other does not.

snd_hda_codec_realtek 298572 1
snd_hda_intel 24479 2
snd_hda_codec 86743 2 snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 6392 1 snd_hda_codec
snd_seq 53791 0
snd_seq_device 6191 1 snd_seq
snd_pcm 80190 2 snd_hda_intel,snd_hda_codec
snd_timer 19892 2 snd_seq,snd_pcm
snd 63984 12 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer
soundcore 6576 1 snd
snd_page_alloc 7559 2 snd_hda_intel,snd_pcm

[Bvasselle (bvasselle)]

(In reply to comment #9)
> (In reply to comment #8)
> > "Buggy" code can be linked to the new memcpy@@GLIBC_2.14 by just recompiling,
> > no? That doesn't really solve anything.
>
> It solves everything. If you just relink without retesting you're an idiot and
> acting irresponsible.

Nobody is interested in an optimization in lib C that would at best gain less than the simple fact of calling the function.

Everybody is interested in using the code that idiots may produce.

[Hjl-tools (hjl-tools)]

Created attachment 5323
A patch

This works for me.

[Jakub Jelinek (jakub-redhat)]

This is not correct:
1) glibc 2.13 has been released already, so new symbol versions must be GLIBC_2.14
2) you do it only on x86_64, therefore you should add it into sysdeps/x86_64/Versions (though, you will need to add GLIBC_2.14 to toplevel Versions.def too)

[horsley1953 (horsley1953-redhat-bugs)]

Created attachment 487982
Program to fix relocation entries in libflashplayer.so

I got ambitious today for some reason and wrote this silly program that takes
an x86_64 shared lib as an argument and fixes any relocation entries that
point to memcpy so they point to memmove instead. It is much faster than the
script posted earlier in this bugzilla.

Sample results:

readelf -r test.so | fgrep mem
000000bf5968 008f00000007 R_X86_64_JUMP_SLO 0000000000000000 memset + 0
000000bf5ea8 014700000007 R_X86_64_JUMP_SLO 0000000000000000 memchr + 0
000000bf63d8 020400000007 R_X86_64_JUMP_SLO 0000000000000000 memmove + 0
000000bf64e0 020400000007 R_X86_64_JUMP_SLO 0000000000000000 memmove + 0
readelf -r libflashplayer.so | fgrep mem
000000bf5968 008f00000007 R_X86_64_JUMP_SLO 0000000000000000 memset + 0
000000bf5ea8 014700000007 R_X86_64_JUMP_SLO 0000000000000000 memchr + 0
000000bf63d8 020400000007 R_X86_64_JUMP_SLO 0000000000000000 memmove + 0
000000bf64e0 022700000007 R_X86_64_JUMP_SLO 0000000000000000 memcpy + 0

Seems to work for me.

[rian (rian-redhat-bugs)]

FWIW Conventional wisdom says Linus's intuition to alias memcpy to memmove is favorable. Page 43, Section 2.6 of "The Practice of Programming" by Kernighan and Pike states:

"The ANSI C standard defines two functions: memcpy , which is fast but might overwrite memory if source and destination overlap; and memove, which might be slower but will always be correct. The burden of choosing correctness over speed should not be placed upon the programmer; there should be only one function."

Torvalds, Kernighan, Pike: 1
glibc developers: 0

[lukas+fedora (lukas+fedora-redhat-bugs)]

Up to now I thought it was a reasonable assumption that memcpy copies forwards (at least for not overlapping memory areas).
I'm currently thinking about the case that you have a memory mapped device file from which you want to copy some data and it has to be forwards. With the new random behavior it will break.

If the assumption was always correct in the past, I don't think it is right to change that now. At least every documentation of memcpy should have a big warning that the direction of the copy is random.

[ricky (ricky-redhat-bugs-1)]

I completely agree with Linus here; whilst I'm far from a typical desktop end-user, I feel that something, particularly concerned with multimedia (i.e. having a break/having fun) should be fixed as a high priority, particularly when the popularity of such a thing makes people decide not to use Fedora because it doesn't work out of the box.

If I didn't happen to work with so many RHEL-based systems and also have a curiosity which devours my time, I wouldn't have investigated so thoroughly and may have just switched to a different distro by now.

Fedora 15, with GNOME 3, is clearly showing a consensus amongst those in the Fedora project that they want to improve the user experience, particularly so for the type of users who don't visit bugtrackers; by not somehow fixing the root cause of this problem or working around it until it is fixed, the Fedora project is going back on itself.

[seg (seg-redhat-bugs)]

If you don't want the burden of choosing correctness over speed, don't program in C.

Does anyone read the thread? Flash works fine, its only people insisting on using an unsupported (by Adobe themselves) 64-bit preview version of flash having a problem.

[ricky (ricky-redhat-bugs-1)]

You mean the same unsupported 64-bit version that performs anywhere near to acceptable (as opposed to other non-Adobe plugins), despite the issue with glibc?

It does nobody any good to hide behind 'unsupported', 'preview', 'less-than-desirable alternative works fine' when it's clear as to how popular and desired this plugin is to have working. It's fine to use them as an excuse for something breaking, but not to ignore the problem.

Nobody wants a crippled web experience on their 64-bit desktop OS.

[seg (seg-redhat-bugs)]

I never said anything about non-Adobe plugins. You're projecting. Read the thread.

You should be using the 32-bit Adobe Flash plugin, with nspluginwrapper. That is the supported configuration, both by Adobe, and "unofficially" by Fedora. There's a reason nspluginwrapper was developed in the first place.

[hdfssk (hdfssk-redhat-bugs)]

FWIW my problem that led to this bug was not related to the flash plugin, see Comment #220.

Inre Comment #248 & Comment #250: please knock that attitude off, Callum; stuff like "read the thread" and "don't program in C" aren't going to make anything better, though they might lead to another argument (and there've been enough of those already!)

[felipe.contreras (felipe.contreras-redhat-bugs)]

(In reply to comment #248)
> If you don't want the burden of choosing correctness over speed, don't program
> in C.

Have you measured the speed difference between memcpy and memmove? No? Then don't assert that one is faster than the other, because they aren't. This has been demonstrated in the thread with numbers.

> Does anyone read the thread? Flash works fine, its only people insisting on
> using an unsupported (by Adobe themselves) 64-bit preview version of flash
> having a problem.

AFAIK it happens on 32-bit too, it's only a matter of time before the "square" code gets into the "non-preview" version of Flash.

Anyway, this bug is _not_ about Flash, it's about glibc. Anything that uses memcpy can be affected silently. How much code is misbehaving thanks to this change? It's impossible to know.

For more examples of issues, see:
http://lwn.net/Articles/414496/

So, not fixing this bug means silently breaking stuff with _zero_ gain.

Now, can we rename this bug to:
"memcpy acts randomly (and differently) with overlapping areas"

Or shall I create a new one and make this one depend on that?

[seg (seg-redhat-bugs)]

(In reply to comment #252)
> (In reply to comment #248)
> > If you don't want the burden of choosing correctness over speed, don't program
> > in C.
>
> Have you measured the speed difference between memcpy and memmove? No? Then
> don't assert that one is faster than the other, because they aren't. This has
> been demonstrated in the thread with numbers.

Kindly read comment #99.

> > Does anyone read the thread? Flash works fine, its only people insisting on
> > using an unsupported (by Adobe themselves) 64-bit preview version of flash
> > having a problem.
>
> AFAIK it happens on 32-bit too,

Read the thread. No one has said any such thing. If you have experienced otherwise, please let us know.

> it's only a matter of time before the "square"
> code gets into the "non-preview" version of Flash.

A hypothetical statement that makes a lot of assumptions about Adobe's development process. Do you work for Adobe?

They could also have committed a fix into their source tree months ago and its just a matter of time until they release a fixed version of the 64-bit plugin.

I don't work for Adobe and I don't see you with an @adobe.com email so my hypothetical statements are just as good as yours.

> Anyway, this bug is _not_ about Flash, it's about glibc. Anything that uses
> memcpy can be affected silently. How much code is misbehaving thanks to this
> change? It's impossible to know.

If a tree falls in the woods...

> For more examples of issues, see:
> http://lwn.net/Articles/414496/

Just read it, squashfs fixed their code, problem solved. It also links to this:

http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278

"This patch includes optimized 64bit memcpy/memmove for Atom, Core 2 and
Core i7. It improves memcpy by up to 3X on Atom, up to 4X on Core 2 and
up to 1X on Core i7. It also improves memmove by up to 3X on Atom, up to
4X on Core 2 and up to 2X on Core i7."

> So, not fixing this bug means silently breaking stuff with _zero_ gain.

Your "zero gain" premise is contradicted by at least two Intel engineers.

And Linus never said what hardware he was performance testing on, so we don't know that his testing contradicts the Intel engineers statements.

The Intel engineer in comment #99 even gave a credible technical explanation as to why it is faster to copy backwards, that makes sense if you know anything about modern processor designs. Presumably Intel understands how their own CPUs work.

You're going to have to give a lot more than just your word as to why we should disbelieve the Intel engineers.

[torvalds (torvalds-redhat-bugs)]

(In reply to comment #253)
>
> Kindly read comment #99.

Bullshit. Read comment #132. Even if you want to copy backwards, there is absolutely zero reason to not check the overlapping case first, to see that you don't do it wrong.

Why is that so hard for people to understand?

The _only_ reason to do memcpy() that clobbers overlapping areas is that the code is fast BECAUSE IT IS SIMPLE. So if you were to use "rep movsb" as the memcpy implementation, then you have a good argument why it does the overlapping case wrong - it's so simple as to be brainless.

But once you do what the glibc memcpy does, there is just no excuse any more for it.

[ricky (ricky-redhat-bugs-1)]

Precisely, it's a trade-off, not an improvement. The argument for keeping it is as good as saying: "Let's make it do nothing at all - at least it'll be faster!".

[felipe.contreras (felipe.contreras-redhat-bugs)]

(In reply to comment #253)
> (In reply to comment #252)
> > (In reply to comment #248)
> > > If you don't want the burden of choosing correctness over speed, don't program
> > > in C.
> >
> > Have you measured the speed difference between memcpy and memmove? No? Then
> > don't assert that one is faster than the other, because they aren't. This has
> > been demonstrated in the thread with numbers.
>
> Kindly read comment #99.

Hopefully Linus has answered this one.

> > > Does anyone read the thread? Flash works fine, its only people insisting on
> > > using an unsupported (by Adobe themselves) 64-bit preview version of flash
> > > having a problem.
> >
> > AFAIK it happens on 32-bit too,
>
> Read the thread. No one has said any such thing. If you have experienced
> otherwise, please let us know.

I did read the thread, everybody mentioned 64-bit instead of "the square version", but Pablo Rodríguez mentioned he experiences the issue in 32-bit too. Anyway, I tried on my 32-bit laptop, and it doesn't seem to run, so I guess that's a different issue.

> > it's only a matter of time before the "square"
> > code gets into the "non-preview" version of Flash.
>
> A hypothetical statement that makes a lot of assumptions about Adobe's
> development process. Do you work for Adobe?
>
> They could also have committed a fix into their source tree months ago and its
> just a matter of time until they release a fixed version of the 64-bit plugin.
>
> I don't work for Adobe and I don't see you with an @adobe.com email so my
> hypothetical statements are just as good as yours.

The 'square' plug-in is 10.3, and the current one is 10.2. If you don't put code in 10.3 beta that you would use in 10.3 final, what's the point of the beta then? Sure, maybe they fixed that internally, but maybe not.

> > Anyway, this bug is _not_ about Flash, it's about glibc. Anything that uses
> > memcpy can be affected silently. How much code is misbehaving thanks to this
> > change? It's impossible to know.
>
> If a tree falls in the woods...
>
> > For more examples of issues, see:
> > http://lwn.net/Articles/414496/
>
> Just read it, squashfs fixed their code, problem solved.

No, problem not solved. That's _one_ issue. Can you be certain that there are no issues lingering there? How many millions of line of code can be affected by this? Sure, we've found so far a few issues that were obvious, but there could be many more hidden, specially if they are subtle, or tricky to trigger.

> It also links to this:
>
> http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278
>
> "This patch includes optimized 64bit memcpy/memmove for Atom, Core 2 and
> Core i7. It improves memcpy by up to 3X on Atom, up to 4X on Core 2 and
> up to 1X on Core i7. It also improves memmove by up to 3X on Atom, up to
> 4X on Core 2 and up to 2X on Core i7."

So? memcpy can be improved, and so can memmove. But they are the same. So again, this potential breakage provides _zero_ gain.

> > So, not fixing this bug means silently breaking stuff with _zero_ gain.
>
> Your "zero gain" premise is contradicted by at least two Intel engineers.
>
> And Linus never said what hardware he was performance ...

[Felipe Contreras (felipec)]

So we have two solutions:

1) The solution proposed by Linus Torvalds, attachment #5264

Advantages: everything works the same as before
Disadvantages: a few extra cycles in certain memcpy's

2) The solution proposed by Ulrich Drepper, attachment #5323

Advantages: old binaries keep working
Disadvantages: newly compiled code remains affected

Clearly 1) is the most sensible solution as the only advantage of 2) is a few cycles, and has drastic disadvantages.

[Andreas Oberritter (mtdcr)]

I've added eglibc, because the regression is caused by an upstream patch to glibc, which changed the semantics of memcpy. This patch is likely to have caused subtle problems in other packages than adobe-flashplugin, too.

I wonder why this bug gained so much attention at Fedora but didn't receive any comments here. Is this a duplicate of another bug report I couldn't find?

Please either revert the upstream patch or alias memcpy to memmove as suggested in https://bugzilla.redhat.com/show_bug.cgi?id=638477 before releasing 11.04.

[Andreas Oberritter (mtdcr)]

Adobe Flash Player bug tracker URL: https://bugs.adobe.com/jira/browse/FP-5739

[Andreas Oberritter (mtdcr)]

The patch which caused the regression:
http://sourceware.org/git/?p=glibc.git;a=commit;h=6fb8cbcb58a29fff73eb2101b34caa19a7f88eba

[siarhei.siamashka (siarhei.siamashka-redhat-bugs)]

(In reply to comment #254)
> (In reply to comment #253)
> >
> > Kindly read comment #99.
>
> Bullshit. Read comment #132. Even if you want to copy backwards, there is
> absolutely zero reason to not check the overlapping case first, to see that you
> don't do it wrong.

I love how you use the words 'absolutely' and 'zero reason' :) Ever heard about http://en.wikipedia.org/wiki/Cargo_cult_programming ?

> Why is that so hard for people to understand?
>
> The _only_ reason to do memcpy() that clobbers overlapping areas is that the
> code is fast BECAUSE IT IS SIMPLE. So if you were to use "rep movsb" as the
> memcpy implementation, then you have a good argument why it does the
> overlapping case wrong - it's so simple as to be brainless.
>
> But once you do what the glibc memcpy does, there is just no excuse any more
> for it.

That's just pure bullshit. Making assumptions about how exactly undefined behavior might manifest itself with various C library implementations is not something that you should rely on when developing software. What is so hard to understand here?

GNU/Linux is not the only OS which tries to be POSIX compatible, glibc is not the only C library and gcc is not the only C compiler. What you and your fanboys are doing here is just an aggressive promotion of a trivial memcpy misuse bug into a new de-facto standard. I would be really upset if "it is safe because glibc is known to work this way" becomes a common practice and a valid excuse for not fixing bugs.

There are many bugs being introduced and fixed in various software daily. What makes this particular trivial bug so special that it even deserves an update for the C language standard? Especially considering that there are multiple tools capable of detecting this overlapping memcpy problem and it is almost nonexistent in practice.

This bug also highlights a major weakness of the Flash plugin. For the various security problems not addressed over long periods of time they might have an excuse, maybe the bugs were not so easy to fix. But based on how this trivial memcpy issue is being handled, looks like Adobe just does not have a sane process for releasing updates and security fixes. This is very disturbing.

[awilliam (awilliam-redhat-bugs)]

Once again: this bug is not the right place to discuss this. Fedora is not where significant changes to glibc behaviour happen. Fedora Bugzilla is not the right place to discuss making them. There is already an upstream bug for this. Fedora will follow the approach that is decided on upstream, when it is decided on upstream. Commenting here is achieving precisely nothing.

[davidsen (davidsen-redhat-bugs)]

(In reply to comment #257)

> There are many bugs being introduced and fixed in various software daily. What
> makes this particular trivial bug so special that it even deserves an update
> for the C language standard? Especially considering that there are multiple
> tools capable of detecting this overlapping memcpy problem and it is almost
> nonexistent in practice.
>
Why are developers fighting this so hard? If upstream introduces new code to the kernel which breaks existing programs, it gets fixed in Fedora. Here old versions of the library work with existing code and not with the update. Why is good to fix kernel bugs and bad to fix library bugs.

I'm sure RHEL will not introduce a change which breaks existing programs, why should Fedora? Put the "standard conforming" library in FC15 and be happy, hopefully it will break GNOME3. But unless the Fedora team intends to rewrite and maintain all of the other Fedora software which is using the wrong move, the place to fix the disfunction is at the library, and not deliberately break programs in the names of pedantic adherence to a standard.

> This bug also highlights a major weakness of the Flash plugin. For the various
> security problems not addressed over long periods of time they might have an
> excuse, maybe the bugs were not so easy to fix. But based on how this trivial
> memcpy issue is being handled, looks like Adobe just does not have a sane
> process for releasing updates and security fixes. This is very disturbing.

I'm less disturbed by slow support from Adobe than calling a bug a feature by Fedora.

[jakub (jakub-redhat-bugs-1)]

Perhaps because it is clearly documented?

ISO C99, 7.21.2.1:
"If copying takes place between objects that overlap, the behavior is undefined."
Ditto ISO C90, 7.11.2.1, Unix 98, POSIX 2003, POSIX 2008.
man 3 memcpy also clearly says
"The memory areas should not overlap. Use memmove(3) if the memory areas do overlap."
After all that is the only difference between memcpy and memmove.

glibc certainly doesn't guarantee bug compatibility, backward compatibility is only provided for correctly written programs that don't trigger undefined behavior. I'm not sure why you are rising RHEL here, the upcoming major version of RHEL will certainly provide the upstream memcpy version.

[felipe.contreras (felipe.contreras-redhat-bugs)]

(In reply to comment #260)
> Perhaps because it is clearly documented?

So? The purpose of Fedora is not to follow some specification documentation, it is to provide stable, reliable, useful system.

If breaking applications was done in favor of some drastic performance improvements, that might be ok, following API break path that upstream is planning to do.

But there's nothing like that. You are fighting to protect a vacuum. You want to break applications in order to gain _nothing_.

I guess it's more important to make a few developers at RedHat feel good about themselves because they manage to close a bug without moving a finger, and claiming POSIX correctness, than to make the system more reliable.

Congratulations, you have knowingly made the system more unreliable in order to gain nothing.

[Felipe Contreras (felipec)]

Actually, why not have both? I think this plan would fit everyone:

1) Apply Linus' patch

Both to 2.13 and 2.14, this would not introduce any issues and would restore back the previous behavior, so applications would still work. As I mentioned before, the disadvantages are minimal.

2) Apply H.J. Lu's patch

This would go to 2.14, but not only to x86 but all architectures, and add an overlap check, and when triggered issue a crash.

This would allow old binaries to keep working on 2.14, but newly compiled ones would crash if they are doing something wrong. This would allow all the users of glibc to fix their code for the impending changes.

3) Remove overlap checks

On 2.15, after a transition period, the overlap checks can be removed, and thus save the few extra cycles.

This has all the advantages of all the proposals, and makes it easy to fix the applications that are using memcpy wrong.

[Bvasselle (bvasselle)]

(In reply to comment #17)
> Actually, why not have both? I think this plan would fit everyone:

No, it does not. It certainly does not.

It is not only the problem of recompiling the existing code, it's also the problem of fixing it and re-qualifying it. This plan has a huge cost... and it's vain.

The contract C programmers have with C and the C library is clear: we accept a fair amount of inefficency, but we don't have to program in assembly nor care about the system's internals. How many people still use the C library when it comes to be important to gain an addition plus a comparison?

The problem we're facing just made this fact plain: there is no reason why memcpy should not be memmove.

[Felipe Contreras (felipec)]

(In reply to comment #18)
> (In reply to comment #17)
> > Actually, why not have both? I think this plan would fit everyone:
>
> No, it does not. It certainly does not.
>
> It is not only the problem of recompiling the existing code, it's also the
> problem of fixing it and re-qualifying it. This plan has a huge cost... and
> it's vain.

I understand that, but it's better than the current alternative that Ulrich is more likely to merge, which is basically to do nothing.

[Felipe Contreras (felipec)]

Created attachment 5341
Patch to check for overlaps

I'm trying this patch to find out how many things in the system use overlapping memcpy, however, it doesn't seem to cause any crashes... Can anyone spot something wrong?

[shigorin (shigorin-redhat-bugs)]

(In reply to comment #253)
> Why is that so hard for people to understand?
Maybe because they failed to grok Postel's Law?

In the meanwhile, folks thank you for the master class and point fingers at fedora developers: http://avva.livejournal.com/2323823.html (in Russian)

2 jj: je svedomi? :( there are too few _correctly_ written programs in the world

[linuxover (linuxover-redhat-bugs)]

(In reply to comment #101)
> I'd personally suggest that glibc just alias memcpy() to memmove().

I think You aren't right :)

You suggest to provide *one* of many undocumented behaviours. What do You think do with other undocumented behaviours?

for example: memcpy can (or could) be used to propagate a pattern:

strcpy(buffer, "abc");
memcpy(buffer + 3, buffer, 100);

it will (or would) fill buffer by repeating "abcabcabc..."

Someone can invent the other undocumented variant. If You try provide all these variants You will have no time to do something in linux kernel.

I think that invalid (adobe's) code must be fixed anyway. memcpy shouldn't be alias to memmove.

[Nick Shaforostoff (shafff)]

i'd like to vote for having memcpy and memmove identical.

(unless there are benchmarks that are showing that perf difference is high)

[linuxover (linuxover-redhat-bugs)]

> I'm no great fan of flash but it's an essential part of life on the web these
> days and I had thought that the Fedora project had finally put its days of
> broken flash support behind it.

to watch Youtube I use gnash. Last version works well.

[milan.kerslager (milan.kerslager-redhat-bugs)]

A programmer should not use side effects of any function.
A glibc should not provide function with performance hit for whatever reason.
It does not matter in what situation has been regression observed.
Glibc has performance regression. This should be fixed.
This has been observed by (broken) Flash (but this hits not only Flash).
Flash had broken code before that. This has been observed by glibc regression.
So Flash should to be fixed too.
Broken design of a function(s) should not leads to broken implementation.
Etc, etc...

[knutjbj (knutjbj-redhat-bugs)]

It is also present in Neverwinter nights.

[Drepper-fsp (drepper-fsp)]

HJ's patch which implements what I proposed is in git.

[Hjl-tools (hjl-tools)]

(In reply to comment #3)
>
> If anything, from a "be nice" standpoint, it would perhaps be good to have a
> "debug mode", that would actually _warn_ - or even assert - about overlapping
> memcpy(). That obviously shouldn't be the default (since that only helps

You can use LD_AUDIT to do it today.

[Colin Watson (cjwatson)]

This has been fixed (at least to avoid breaking old binaries) here:

  http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=0354e355014b7bfda32622e0255399d859862fcd

I wonder what the right way to backport this is, though. Matthias, do you think it's OK to end up with a GLIBC_2_14 symbol? We'd have to be rather careful about the .symbols files until such time as we have a real 2.14 release.

[Matthias Klose (doko)]

A test build is currently building in the ubuntu-toolchain-r archive. Please check the build once it is completed. The mem* multiarch functions are disabled in this build. It's a temporary change, and will be reverted with glibc-2.14.

see https://launchpad.net/~ubuntu-toolchain-r/+archive/ppa/

add to /etc/apt/sources.list:

deb http://ppa.launchpad.net/ubuntu-toolchain-r/ppa/ubuntu natty main
deb-src http://ppa.launchpad.net/ubuntu-toolchain-r/ppa/ubuntu natty main

[Markus Birth (mbirth)]

There's a patch for the current flashplayer64: http://www.linux.org.ru/forum/talks/5663681 . Works fine for me. Also while parsing through Google results, I found that this only affects MP3 sound, not AAC. YouTube's 240px videos (and some very old ones) use MP3 sound, all higher resolutions use AAC. Just FYI.

[Matthias Klose (doko)]

Markus, please could you recheck without the "patch", but with the proposed eglibc version?

[Jacob Peddicord (jpeddicord)]

I gave it (the rebuilt eglibc) a go, and it appears to solve the issue. Haven't noticed any side-effects, either.

[Launchpad Janitor (janitor)]

This bug was fixed in the package eglibc - 2.13-0ubuntu12

---------------
eglibc (2.13-0ubuntu12) natty; urgency=low

  * For memcpy-ssse3, enable chk symbols in static builds. LP: #726802.
  * Disable the memcpy multiarch implementaiton on x86_64. LP: #727064.
  * Merge from Debian:
    - Add patches/i386/cvs-cacheinfo.diff to fix empty LEVEL*CACHE* getconf()
      entries for some CPU. Closes: #609389.
 -- Matthias Klose <email address hidden> Tue, 05 Apr 2011 10:54:32 +0200

[brendan.jones.it (brendan.jones.it-redhat-bugs)]

*** Bug 680802 has been marked as a duplicate of this bug. ***

[riku.seppala (riku.seppala-redhat-bugs)]

http://sources.redhat.com/bugzilla/show_bug.cgi?id=12518 is now marked as FIXED.
So... ?

[awilliam (awilliam-redhat-bugs)]

so, that patch should get pulled downstream now.

[Bvasselle (bvasselle)]

(In reply to comment #4)
> The existence of code written by people who should never have been allowed to
> touch a keyboard cannot be allowed to prevent a correct implementation. If
> there is a large bod of code out there we can work around the issue for that.
>
Don't you see it is just NOT a correct implementation?

[Felipe Contreras (felipec)]

Created attachment 5660
Patch to check for overlaps

Actually the code from Linus had a bug in the 'cmp' checks, here's the updated version.

I just started to run my Fedora system with this, and I already see crashes in pulseaudio and readahead-collector. I will continue running this for a bit, but I think it's pretty clear that we should not assume that all applications in a typical system have been using memcpy properly.

So, again, I think we need at least a transition period so that people can detect and fix the issues.

[felipe.contreras (felipe.contreras-redhat-bugs)]

Created attachment 491126
x86_64: workaround for new memcpy behavior

I have backported the fix to 2.13, and I've launched a koji build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2992294

Enjoy :)

[felipe.contreras (felipe.contreras-redhat-bugs)]

Created attachment 491127
memcpy-ssse3: add overlap checks

I used Linus' patch as a guide to add overlap checks that would crash improper apps, and tried to boot my Fedora 14 system with it.

I noticed pulseaudio and readahead-collector crash, so they must be doing something wrong.

I say if Fedora cares about the quality of the full system something like this should be done to find all the bad code.

[jc1da.3011 (jc1da.3011-redhat-bugs)]

I'm testing testing Fedora 15 ... Problem is fixed now

[jakub (jakub-redhat-bugs-1)]

(In reply to comment #270)
> Created attachment 491126 [details]
> x86_64: workaround for new memcpy behavior
>
> I have backported the fix to 2.13, and I've launched a koji build:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2992294

This is ABI incompatible library, so please don't spread this out.

[brentrbrian (brentrbrian-redhat-bugs)]

Will this be made available as an yum update on FC14 ?

[felipe.contreras (felipe.contreras-redhat-bugs)]

Created attachment 491198
x86_64: fix for new memcpy behavior (try 2)

Here's a second try, should achieve the same thing, but ABI compatible.

[felipe.contreras (felipe.contreras-redhat-bugs)]

(In reply to comment #275)
> Created attachment 491198 [details]
> x86_64: fix for new memcpy behavior (try 2)
>
> Here's a second try, should achieve the same thing, but ABI compatible.

Here's the corresponding koji build, now it's ABI compatible.

[felipe.contreras (felipe.contreras-redhat-bugs)]

http://koji.fedoraproject.org/koji/taskinfo?taskID=2992729

[felipe.contreras (felipe.contreras-redhat-bugs)]

Thanks to Ulrich Drepper I managed to write a simple check to find memcpy overlaps issues system-wide and I created a tracking but to link my findings so far. It would be useful if other people ran this on their systems as well:

Bug #696096.

[Vincent+libc (vincent+libc)]

(In reply to comment #18)
> The problem we're facing just made this fact plain: there is no reason why
> memcpy should not be memmove.

If these two functions should behave in the same way, then why not all programmers use memmove (which has fewer requirements)?

If memcpy is called while the objects overlap, the bug is not necessarily that memmove should have been used instead. The cause may be an incorrect size. So, with this point of view, it should be safer to abort than letting the program behave in an uncontrolled way.

(In reply to comment #25)
> So, again, I think we need at least a transition period so that people can
> detect and fix the issues.

But it may be difficult to detect the issues. For instance, zsh was affected by a similar problem (now fixed in CVS only) with the optimized strcpy, but to detect the problem, it involves keyboard input:

  http://www.zsh.org/mla/workers/2011/msg00533.html
  http://www.zsh.org/mla/workers/2011/msg00544.html

For strcpy, this is even worse, as there is no strmove function, so that either programmers have to write non-portable code or they have to reimplement a naive version of strcpy or find some other workaround, such as memmove + strlen:

  http://www.zsh.org/mla/workers/2011/msg00542.html

I suppose that if this has been done for memcpy, then strcpy should also be patched in some way...

[Felipe Contreras (felipec)]

(In reply to comment #26)
> (In reply to comment #25)
> > So, again, I think we need at least a transition period so that people can
> > detect and fix the issues.
>
> But it may be difficult to detect the issues. For instance, zsh was affected by
> a similar problem (now fixed in CVS only) with the optimized strcpy, but to
> detect the problem, it involves keyboard input:

Yes, it is difficult, that's why I think it should be enabled globally.

BTW. Here's another issue on zsh I found while enabling the memcpy checks:
https://bugzilla.redhat.com/show_bug.cgi?id=698439

[simon.lewis (simon.lewis-redhat-bugs)]

Ubuntu is also using the MEMCPY hack - the deb package refers to redhat bug #638477

See http://www.ubuntuupdates.org/packages/show/301005

I guess Ubuntu is wating for redhat to fix glibc.......

[bill-bugzilla.redhat.com (bill-bugzilla.redhat.com-redhat-bugs)]

Adobe didn't fix this in Flash 10.3. :( I applied Ray Strode's script to the 10.3 binary and it still appears to work.

2.6.35.13-91.fc14.x86_64
glibc-2.13-1.x86_64

[felipe.contreras (felipe.contreras-redhat-bugs)]

(In reply to comment #280)
> Adobe didn't fix this in Flash 10.3. :( I applied Ray Strode's script to the
> 10.3 binary and it still appears to work.

Flash 10.3 is ambiguous, 10.3.162 is flash "square" preview 3 for 64-bit systems, 10.3.181.14 is 10.3 final, for 32-bit systems.

[Baptiste Coudurier (baptiste-coudurier)]

May I ask why has the fix been reverted in oneiric ?

[m.heiming (m.heiming-redhat-bugs)]

Thx a bunch for Linus quick patch, saves me from the annoying sound with youtube videos on FC 14...

[brentrbrian (brentrbrian-redhat-bugs)]

Patch works for me as well

[mike (mike-redhat-bugs-1)]

Andreas or Jakub, what is the status of this?

I just ran into an overlapping memcpy() in a piece of third-party proprietary software used by my $DAYJOB. It seems this memcpy() change is in RHEL6 as the customers effected are running RHEL6. I can, of course, fix the problem, but other softwares out there may be effected, too. RHEL6 may need to be fixed as other proprietary houses may not be so friendly.

[mike (mike-redhat-bugs-1)]

glibc-2.14-3 still exhibits the new, backwards behavior for me. (Fedora 15)

Is this expected?

[mjg (mjg-redhat-bugs)]

For anything built against new glibc, yes. Old binaries should pick up the old memcpy behaviour.

[felipe.contreras (felipe.contreras-redhat-bugs)]

FTR the public beta of Flash 11 seems to have the problem fixed.

[sebastien.major (sebastien.major-redhat-bugs)]

Does the subject can be a concrete one ?
I did not read as carefully as evidently needed but, as entirely user under Linux and after GNU/Linux since 1994, I think we could just get away from this talk and move the debate target.

Super : adobe done the new glibc update.

In my humble opinion, we need all people to raise up Linux and not read comments that disturb the project. If Linus Torvalds said ... We must follow, unless, it's stupid and get us or another in danger ! Completely agree with the facts of he told.

What about have memcpy be exact aliasing to memset and memcpy32, memcpy64, memcpy128, ... be other functions ?

Please, don't bicker yourselves about this one year subject Bug. I think we need you for largely others things.

[kolyshkin (kolyshkin-redhat-bugs)]

Guys,

Thanks for the solution! I was tired of manually adding LD_PRELOAD to firefox/google-chrome start script, so I ended up automating the process using RPM triggers. Now all I (and you) need to do is to install flash-fix RPM and forget about the problem.

Get the stuff from here: http://kir.sacred.ru/flash-fix/

[riku.seppala (riku.seppala-redhat-bugs)]

Adobe has updated flash plugin that fix this. Works for me.

http://labs.adobe.com/downloads/flashplayer11.html

[noloader (noloader-redhat-bugs)]

(In reply to comment #152)
> ...
> I would like to urge anyone with any political power withing Fedora to get this
> problem dealt with immediately. An organization this big and mature shouldn't
> be having trouble dealing with this sort of thing, fix it, make certain it
> won't happen again and move on.
Unfortunately, Fedora politcos will probably not be able to get Adobe to move any faster or do a better job with their software. Adobe has a chronic, progressive problems (which, not surprisingly, spills over into security related defects). There's a reason Apple selectively bans Adobe from their platforms.

"Adobe surpasses Microsoft as favorite hacker’s target" [1]
"Adobe predicted as top 2010 hacker target" [2]
"Adobe products are legendary for their insecurity." [3]

Adobe security related history: http://www.google.com/#q=adobe+pointer+site:securityfocus.com

[1] http://lastwatchdog.com/adobe-surpasses-microsoft-favorite-hackers-target/
[2] http://www.theregister.co.uk/2009/12/29/security_predictions_2010/
[3] http://techcrunch.com/2011/08/20/revenge-of-the-killer-script-kiddies/

[vik (vik-redhat-bugs)]

Garbled audio on Fedora 14 with flash also happens when using:
http://demo.bigbluebutton.org/

The workaround in this case has no effect.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Zorael (zorael)]

This affects me with the 64-bit plugin of Flash 11rc1 as downloaded from Adobe's site (flashplayer11_rc1_install_lin_64_090611.tar.gz). The machine is a sandy bridge i7 running oneiric, dist-upgraded from natty. I work around the issue by preloading an override of memcpy (source extracted from a Fedora flash-fix package; http://kir.sacred.ru/flash-fix/repo).

Luckily Flash 11 was released today (Oct 4th), and with it I'm no longer experiencing this bug.
http://kb2.adobe.com/cps/919/cpsid_91932.html

[Sergio Cuellar Valdes (herrsergio)]

It is still happening in Ubuntu 12.04

ii flashplugin-installer 11.2.202.238ubuntu0.12.04.1 Adobe Flash Player plugin installer

[Tudor Bosman (tudorb)]

FYI, this bug has bitten me in a different way: memcpy() copying backwards defeats the MADV_SEQUENTIAL flag to madvise(). A trivial file copier implementation (mmap source, mmap destination, set MADV_SEQUENTIAL, memcpy from source to destination) would perform much worse on machines that support SSSE3 than on machines that don't because of this bug.

(Before anyone tells me that I should copy files using read() and write(), my actual usage pattern was more complex, but the details are irrelevant.)

[Neleai (neleai)]

On Mon, Aug 12, 2013 at 05:19:54PM +0000, tudorb at gmail dot com wrote:
> --- Comment #28 from Tudor Bosman <tudorb at gmail dot com> ---
> FYI, this bug has bitten me in a different way: memcpy() copying backwards
> defeats the MADV_SEQUENTIAL flag to madvise(). A trivial file copier
> implementation (mmap source, mmap destination, set MADV_SEQUENTIAL, memcpy from
> source to destination) would perform much worse on machines that support SSSE3
> than on machines that don't because of this bug.
>
Wait, do you have overlapping source and destination areas? If so then a
backward copy is necessary.

Or is backward copy called for not overlapping areas?
I have a patch that could call backward copy only if src-n < dest < src+n holds.

> (Before anyone tells me that I should copy files using read() and write(), my
> actual usage pattern was more complex, but the details are irrelevant.)
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Tudor Bosman (tudorb)]

(In reply to Ondrej Bilka from comment #29)
> Wait, do you have overlapping source and destination areas? If so then a
> backward copy is necessary.

Backward copy is often used for non-overlapping areas as it is faster on some Intel processors; see https://bugzilla.redhat.com/show_bug.cgi?id=638477#c99 for an explanation. I was pointing out that it also has the (unintended) behavior of pessimizing mmap()ed file accesses.

[Jackie-rosen (jackie-rosen)]

*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

[davidjoelschwartz (davidjoelschwartz-redhat-bugs)]

"Congratulations, you have knowingly made the system more unreliable in order to gain nothing."

Actually, it's not nothing.

Several bugs were discovered as a result of this change and are now being fixed. This seems to be a somewhat common bug and if it has no consequences, it will continue to become more and more widespread until the day it does have consequences. The sooner that day is, the less it will break.

In addition, in the future if modifications to memcpy do make significant optimizations possible, they won't break things. One of the obstacles to innovation is dealing with code that abuses undocumented behavior and that can lead to a culture of having to maintain bug-for-bug compatibility.

We are talking about a function that exists for exactly one purpose and it being made unsuitable for that purpose.