Description of Problem: We wrote a memcpy replacement in our code base in order to catch calls to memcpy with overlapping regions and surprisingly, instead of catching problems in our own code base, we found out that libpng makes this kind of calls. Here is the stack trace: Stack trace (5085): ------------------- [New Thread 1024 (LWP 5085)] 0x42294519 in __wait4 () from /lib/i686/libc.so.6 #0 0x42294519 in __wait4 () from /lib/i686/libc.so.6 #1 0x423049e4 in __DTOR_END__ () from /lib/i686/libc.so.6 #2 0x42111509 in wait (stat_loc=0xbfffb574) at wrapsyscall.c:167 #3 0x83f149c in doStackTrace () at eval.c:41 #4 0x83f14ee in Arch_LogStackTrace () at eval.c:41 #5 0x83f2802 in memcpy () at eval.c:41 #6 0x4234db73 in png_set_iCCP () from /usr/lib/libpng.so.2 #7 0x42350819 in png_handle_iCCP () from /usr/lib/libpng.so.2 #8 0x42357675 in png_read_info () from /usr/lib/libpng.so.2 #9 0x4141988b in read_png_image () at eval.c:41 #10 0x413cd7d6 in QImageIO::read () at eval.c:41 The call is coming from Qt which is the GUI library we use. Version-Release number of selected component (if applicable): 1.0.5-3 How Reproducible: Very reproducible. Steps to Reproduce: Unfortunately, we cannot provide a test case, but I am hoping that upon inspection of the png_set_iCCP() function, it may be easy to deduce why this is happening.
Why are you using libpng-1.0.5-3 on a 7.1 system? 7.1 came with 1.0.9-1, even 7.0 had 1.0.8-1. 1.0.5-3 was in 6.2; did you select the wrong distribution version? In any case: The only call to memcpy in png_set_iCCP in recent libpng versions is void PNGAPI png_set_iCCP(png_structp png_ptr, png_infop info_ptr, png_charp name, int compression_type, png_charp profile, png_uint_32 proflen) { [...] new_iccp_profile = (png_charp)png_malloc(png_ptr, proflen); [...] png_memcpy(new_iccp_profile, profile, (png_size_t)proflen); } So it is memcpy()'ing a passed parameter to a newly allocated structure. This looks like the calling application is doing something along the lines of foo=(png_charp)malloc(SIZE); /* Put something in there */ free(foo); png_set_iCCP([...], foo, [...]); read_png_image() in your eval.c might be at fault; QImageIO::read() is another possibility (and AFAIK QImageIO does require libpng 1.0.8 or higher). Does this still happen if you update your libpng and possibly Qt?
I am sorry, you are right. The version is 1.0.9-1. I did an rpm -qi on my 6.2 machine rather than the 7.1. read_png_image is in Qt so maybe it's Qt that's making the buggy call?
BTW, we are using Qt 2.3. I checked out the 2.3.1 release notes and they mention some fixes in QImageIO related to saving of png files. Nothing about loading. Hmm...
Beros analysis seems to be correct. The only way that the memcpy call in png_set_iCCP() can be overlapping is a bug in the caller, that would be in Qt.
since RHL8 qt does not use own libpng anymore. It just uses system libpng.