[Bug 2683] Revelation won't work

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=2683

------- Additional Comments From [e-mail]  2005-06-10 03:39 -------
$ ~/wine/wine-cvs/wine
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library
"/lib/tls/libthread_db.so.1".

(gdb) r RevelationClient.exe
Starting program: /home/richard/wine/wine-cvs/loader/wine-pthread
RevelationClient.exe
[Thread debugging using libthread_db enabled]
[New Thread -1209837888 (LWP 24568)]
fixme:ole:OLEPictureImpl_Load Stat failed with hres 80004001

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209837888 (LWP 24568)]
0x7f69f3ba in OLEPictureImpl_Load (iface=0x7fd6f8e8, pStm=0x7fa7dcdc)
    at olepicture.c:1111
1111          memcpy (xbuf, &header, 8);
(gdb) bt
#0  0x7f69f3ba in OLEPictureImpl_Load (iface=0x7fd6f8e8, pStm=0x7fa7dcdc)
    at olepicture.c:1111
#1  0x7f6a0a9d in OleLoadPicture (lpstream=0x7fa7dcdc, lSize=0, fRunmode=0,
    riid=0x43f1c0, ppvObj=0x7fa7fcb8) at olepicture.c:2113
#2  0x00433561 in ?? ()
#3  0x7fa7dcdc in ?? ()
#4  0x00000000 in ?? ()
#5  0x00000000 in ?? ()
#6  0x0043f1c0 in ?? ()
#7  0x7fa7fcb8 in ?? ()
#8  0x00000110 in ?? ()
#9  0x00010026 in ?? ()
#10 0x7fa7e308 in ?? ()
#11 0x7f7cb624 in ?? () from /home/richard/wine/wine-cvs/dlls/user32.dll.so
#12 0x7ffff200 in tls_bitmap ()
   from /home/richard/wine/wine-cvs/dlls/ntdll.dll.so
#13 0x7fd5f7f8 in ?? ()
#14 0x7fd5f618 in ?? ()
#15 0x00000009 in ?? ()
#16 0x7fd5f7f8 in ?? ()
#17 0x7fd5f708 in ?? ()
#18 0x7fd5f7a8 in ?? ()
#19 0x0043cb40 in ?? ()
---Type <return> to continue, or q <return> to quit---
#20 0x0000034c in ?? ()
#21 0x7fd5f6b8 in ?? ()
#22 0x73e76b5c in ?? ()
#23 0x00000064 in ?? ()
#24 0x00000001 in ?? ()
#25 0x7fd5f668 in ?? ()
#26 0x7fd5f528 in ?? ()
#27 0x00000000 in ?? ()
#28 0x7fa7dce0 in ?? ()
#29 0x00000014 in ?? ()
#30 0x7fa7dd20 in ?? ()
#31 0xb7ea1621 in malloc_usable_size () from /lib/tls/libc.so.6
Previous frame inner to this frame (corrupt stack?)
(gdb) p xbuf
No symbol "xbuf" in current context.
(gdb) info locals
hr = 1
headerisdata = 1
xread = 8
toread = 0
header = {3774863615, 1179258880}
magic = 55551
statstg = {pwcsName = 0x7f68f028, type = 3, cbSize = {u = {
      LowPart = 2137580970, HighPart = 2137948840},
    QuadPart = 9182420350458717610}, mtime = {dwLowDateTime = 2144794960,
    dwHighDateTime = 2141707200}, ctime = {dwLowDateTime = 2137583857,
    dwHighDateTime = 2144794960}, atime = {dwLowDateTime = 2137581068,
    dwHighDateTime = 1}, grfMode = 2137948840, grfLocksSupported = 2137648298,
  clsid = {Data1 = 2137948840, Data2 = 20428, Data3 = 32622,
    Data4 = "\uffff\u06e7\177\uffff\aj\177"}, grfStateBits = 2144794848,
  reserved = 2137948840}
This = (OLEPictureImpl *) 0x7fd6f8e0
__FUNCTION__ = "OLEPictureImpl_Load"
(gdb) p/x header
$1 = {0xe0ffd8ff, 0x464a1000}
(gdb)

WINEDEBUG=snoop,relay:
...
0019:CALL MFC42.275(<unknown, check return>) ret=00433546
0019:RET  MFC42.275(7fa7dc2c) retval=7fa7dad8 ret=00433546
0019:Call oleaut32.OleLoadPicture(7fa7dad8,00000000,00000000,0043f1c0,7fa7fcb8)
ret=00433561
0019:Call ntdll.RtlAllocateHeap(7fd10000,00000008,00000068) ret=7f676670
0019:Ret  ntdll.RtlAllocateHeap() retval=7fd6fbb0 ret=7f676670
0019:Call ntdll.RtlAllocateHeap(7fd10000,00000000,00000028) ret=7f666bf6
0019:Ret  ntdll.RtlAllocateHeap() retval=7fd6fc20 ret=7f666bf6
0019:Call ntdll.RtlAllocateHeap(7fd10000,00000008,00000028) ret=7f666c3b
0019:Ret  ntdll.RtlAllocateHeap() retval=7fd6fc50 ret=7f666c3b
fixme:ole:OLEPictureImpl_Load Stat failed with hres 80004001
...
show that the app is calling mfc42.275 -- the MFC CArchiveStream constructor. 
CArchiveStream::Stat apparently just returns OLE_E_ADVF

I took a look at OLEPictureImpl_Load, and it seems that we should check the
return value from Stat (and also from HeapAlloc) and use other ways to find out
how much memory to allocate.