Created attachment 491687 [details] Code to check for memcpy overlaps Thanks to recent optimizations in glibc where the memcpy happens backwards, it suddenly becomes more important that memcpy is used properly (without overlaps). For reference, see bug #638477 and: http://sources.redhat.com/bugzilla/show_bug.cgi?id=12518 So, we need to check for those system-wide, otherwise there would be silent failures here and there. Right now Flash and squashfs has been identified, but I found others, such as pulsaudio and readahead-collector. In order to check for these easily I'm attaching a memcpy check that can be ld preloaded: % gcc -O2 -fPIC -Wall -Werror memcpy_check.c --shared -o /tmp/memcpy_check.so % echo /tmp/memcpy_check.so > /etc/ld.so.preload
You can use http://people.redhat.com/wcohen/memstomp/
(In reply to comment #1) > You can use > http://people.redhat.com/wcohen/memstomp/ Yeah, but you have to know which process you want to check beforehand. The purpose of this is to check for the *whole* system... Sort of gprof vs perf.
checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking how to create a pax tar archive... gnutar checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for gcc option to accept ISO C99... -std=gnu99 checking whether gcc -std=gnu99 and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -std=gnu99 -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking whether gcc -std=gnu99 needs -traditional... no checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for a sed that does not truncate output... /bin/sed checking for fgrep... /bin/grep -F checking for ld used by gcc -std=gnu99... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 object... ok checking for dlfcn.h... yes checking whether we are using the GNU C++ compiler... (cached) yes checking whether g++ accepts -g... (cached) yes checking dependency style of g++... (cached) gcc3 checking how to run the C++ preprocessor... g++ -E checking for objdir... .libs checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes checking if gcc -std=gnu99 static flag -static works... no checking if gcc -std=gnu99 supports -c -o file.o... yes checking if gcc -std=gnu99 supports -c -o file.o... (cached) yes checking whether the gcc -std=gnu99 linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for ld used by g++... /usr/bin/ld -m elf_x86_64 checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC -DPIC checking if g++ PIC flag -fPIC -DPIC works... yes checking if g++ static flag -static works... no checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for ANSI C header files... (cached) yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking byteswap.h usability... yes checking byteswap.h presence... yes checking for byteswap.h... yes checking for library containing bfd_init... no configure: error: *** libbfd not found
Where are the result of the "test" going to show up? I have several systems, one I KNOW has the buggy flash ...
(In reply to comment #4) > Where are the result of the "test" going to show up? > > I have several systems, one I KNOW has the buggy flash ... It will show as a crash, so abbrt should catch them. I'm talking of course of the test I mentioned in my description of this bug.
the memcpy_check seems to be working: ABRT: won't let me file a bug report on debuginfo-install xulrunner, and xulrunner is crapping out every time it runs (this machine used to run flash without any noticed issues). Please see attached "text file" with cut/paste of abrt dump.
Created attachment 491727 [details] debug info xulrunner
Created attachment 491837 [details] flash failure on Acer Aspire 5734z-4836 This attachment is from a dual pentium T4500
(In reply to comment #8) > Created attachment 491837 [details] > flash failure on Acer Aspire 5734z-4836 > > This attachment is from a dual pentium T4500 That one is not in Fedora, that's Adobe: https://bugs.adobe.com/jira/browse/FP-5739
Unfortunately, I can not test the "sound bug" when the memcpy_check is blowing the flash player out of the water ... all SUGGESTIONS welcome. Is there a "glibc" F14 that I can install to check the fix ?
(In reply to comment #10) > Unfortunately, I can not test the "sound bug" when the memcpy_check is blowing > the flash player out of the water ... all SUGGESTIONS welcome. You are just introducing noise to this bug, so let me explain it _once_. Flash has a bug in the way it uses memcpy, period. All memcpy_check is doing is exposing the bug, by crashing each time memcpy is used wrongly. Blowing Flash out of the what is exactly it's purpose, if that's not what you want, don't use it. If you want your Flash fixed, go to Adobe, this bug is not related to that in any way. I repeat, do _not_ post any Flash adobe related issues here, that is out of topic. > Is there a "glibc" F14 that I can install to check the fix ? Which fix? There is no fix from Adobe. If you want Flash to work you can modify memcpy_check to remove the check: --- #include <string.h> void *memcpy(void *dst, const void *src, size_t n) { return memmove(dst, src, n); } --- But again, that has nothing to do with this bug. Please stop.
Created attachment 493497 [details] Code to check for memcpy overlaps Corrected code to check for overlaps. The check was failing if src == dst.
Created attachment 496332 [details] unzip stacktrace Created with gdb.
Comment on attachment 496332 [details] unzip stacktrace unzip from unzip-6.0-3.fc14.x86_64 crashes when using unzip -t somefile.zip
(In reply to comment #14) > Comment on attachment 496332 [details] > unzip stacktrace > > unzip from unzip-6.0-3.fc14.x86_64 crashes when using unzip -t somefile.zip You should file a separate bug report to the 'unzip' component, and mark it as blocking this one.
Attachment #491727 [details] and and attachment #491837 [details] should be marked as obsolete, probably attachment #496332 [details] too.
Nobody seems to care.