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 <tccow...@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 > > > > > > -- -- Eric Pouech