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
� � �
--
--
Eric Pouech