I was having severe problems under Slackware64-current with the Adobe Flash Player plugin for Firefox. Browsing and watching videos on YouTube was a pain in the neck with the player crashing when opening a couple of tabs, and constant lockups for several seconds while the plugin wrapper that was running it was taking one CPU core for itself.

It seems the problem stems from a recent change in glibc that modified the memcpy implementation and caused a bit of havok in some packages. I'm guessing it's the same change (or a similar one) that caused problems with sysklogd and iptraf, among others, with strcpy and overlapping strings. Remember the patches:

https://bugzilla.redhat.com/attachme...s=1&format=raw
http://git.infodrom.org/?p=infodrom/...f15f3c5af55ccf

Strictly speaking, those are problems in the program source code, but most people seem to think it's a bad idea to provide a memcpy that doesn't work for overlapping strings. A bit of discussion can be found here, with a few priceless comments by Torvalds:

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

It seems the source code for the Flash Player plugin probably contains this bug, as manually modifying the libflashplayer.so binary to replace memcpy calls with memmove calls fixes the problems. At least it clearly did for me.

A quick recipe can be extracted from that bugzilla entry and one of its attachments. For example:

That should modify the binary in place provided it's located at ~/.mozilla/plugins. The resulting binary is not distributable but the recipe is.

I hope this helps.

Unless you have somehow installed a vanilla glibc, this issue will not affect Slackware. I patched glibc to retain the normal memcpy() function with the expected behavior. It's once of the few times that I've done something like that, but reversing the traditional memcopy() direction seems really ill-advised. Even if the result of using memcpy() on overlapping regions has never been defined officially, it was defined unofficially by the way it has always worked.

For the record, this patch was applied to the -1 build of glibc-2.13 in -current, and so the buggy memcpy() has never appeared in any official Slackware package.

1 members found this post helpful.

It's weird then, because I'm running -current and I was having easily reproducible problems yesterday. They immediately disappeared when I patched libflashplayer.so and restarted the browser. I will revert to the vanilla library now and retest again.

By the way, the point raised by Torvalds and others is that memmove already uses the forward direction when possible, so in the most common case it's no different from memcpy. It does, however, use a different direction when the forward direction is not going to work. So there should be no problem using memmove instead of memcpy. It does the right and expected thing in any case.

http://sourceware.org/git/?p=glibc.g...5fcdb6;hb=HEAD

Slackware64-current, using Flash Player 10.3 d162 from Adobe Labs and have experienced no problems with using flash.

I use the square version, not on current, but it has never crashed firefox or the system. If it crashes, it just gives a message saying that it has crashed, and that's it, you can refresh the page and it will come back.

http://labs.adobe.com/downloads/flas...10_square.html

I wouldn't normally use flash player at all, but I decided to play some flash games.

I can't reproduce the problems now, which is a good thing. Sorry for the noise, as it seems modifying the library is not needed at all. My guess is that the problems I had for weeks until some days ago (the player crashed and froze the browser many times) were another bug, probably fixed in any other upgrade, like the Firefox one (I had been using the Firefox 4 betas) and the bad timing of those upgrades made me believe the solution was due to the fix I explained.

When I read that thread in the bug tracker, and its reports of users saying it fixed a lot of stability issues, I tried the solution right away and noticed the problems were no longer happening, and I attributed the solution to the fix immediately. However, now I've followed the same procedure and watched the YouTube videos that triggered the problems, and they no longer happen even with the vanilla libflashplayer.so that I've been using from the site above (latest version is from November).

Good to hear the problem has disappeared.

Glad you made the noise.