the explanations for the bug fix look really strange all the printf use %4.4s form, which will limit output to only 4 chars, whatever the string is terminated or not so the crash doesn't come from here looking quickly at the patch, several remark arise - in the second & third modification to the TRACE call, are you sure the test to srcType is relevant (I don't have the code handy, but it may be a wrong cut & paste) - more importantly, as the %4.4s form implies a 4 char strings, the strings used in case of NULL value must be 4 characters long, instead we may get into trouble A+ 2010/7/18 Tim Cadogan-Cowper tccowper@yahoo.com.au
Three TRACE debug calls in the mmioDescend function of mmio.c attempt to print FOURCC data, by directly casting it to LPCSTR. This is dangerous as: (i) FOURCC data types are DWORDs, i.e. four bytes (one for each char), with no null terminating byte (see http://msdn.microsoft.com/en-us/library/dd375802%28VS.85%29.aspx); and (ii) it assumes the byte order on the host architecture is little endian.
Because the LPCSTR casts are not necessarily null-terminated there will occasionally be buffer overflows in mmio's TRACE debug strings, with a consequent crash to desktop and debug output beginning with 'wine_dbg_vprintf: debugstr buffer overflow...' For a consistent and predictable case where this occurs, see Bug 10280 "Oblivion: Horse Armour Crash" (http://bugs.winehq.org/show_bug.cgi?id=10280).
This patch fixes the problem (and any crashes caused by it) by using a new internal function in mmio - mmioFOURCCToString - which converts FOURCC data to strings that are correctly null-terminated and respect byte order. I have tested with Oblivion and can confirm it fixes Bug 10280 on my machine (ubuntu 10.04). Furthermore the patch will ensure that chunk IDs and fourccTypes are correctly printed in the mmio debug channel (at the moment they are not).
Tim