November 2001 - Wine-Devel - list.winehq.org

fix triggers crash

by Michael Stefaniuc

Hello! I found a bug in ImageList_Merge (the count of the images in the imagelist wasn't set) and the trivial fix Index: imagelist.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/imagelist.c,v retrieving revision 1.43 diff -u -r1.43 imagelist.c --- imagelist.c 2001/09/10 23:09:04 1.43 +++ imagelist.c 2001/11/26 22:37:31 @@ -1918,6 +1918,7 @@ DeleteDC (hdcSrcImage); DeleteDC (hdcDstImage); + himlDst->cCurImage = 1; } return himlDst; =================================================================== triggers with FreeSolitaire (got it from tucows.com) following error (with crash): X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 53 (X_CreatePixmap) Serial number of failed request: 19761 Current serial number in output stream: 19852 This happens with the cvs code from today and I'm pretty shure that it worked perfectly with the cvs code from two days before. And without the patch above the error dosn't get triggered. This seems strange because the error seems to occur in x11drv.StretchBlt and ImageList_Merge dosn't call StretchBlt. To reproduce the crash start FreeSolitaire with the patch above applied, select a solitaire game and start dragging a card around and wine will crash. With --debugmsg +relay it takes sometimes longer to trigger the bug, just release the card I try dragging an other card (i never needed to release the second card yet, wine crashed before). I've attached the last 1000 lines of relay output, hope that helps. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Nov. 27, 2001

Re: winedbg error

by Dave Hawkes

This now fixes all the warnings due to GCC3, so this patch could now be submitted. I still have the problem with the main application C++ code, everytime I rebuild the application it gives a warning on a different class or structure, so the problem may be related to the size of the application (It takes an hour to build on 2 x 1200Mhz machine). Now that I have got the debugger to ignore these errors it continues load the application, but eventually freezes without any warning or error at some point during the rest of the loading process. I'll try and break into gdb to find out what else gives now... Thanks Dave Hawkes ----- Original Message ----- From: "eric pouech" <eric.pouech(a)wanadoo.fr> To: "Dave Hawkes" <daveh-wine(a)cadlink.com> Cc: <wine-devel(a)winehq.com> Sent: Thursday, November 22, 2001 1:04 PM Subject: Re: winedbg error > Dave Hawkes wrote: > > > > Yes, this partially fixed one warning message (which could be due to GCC3), > > though I still get the type mismatches. > well, the warning you got (in Bool type) may be caused by GCC3 (some > other > stabs information), but not the one in Copyfield. this one comes from an > error in MSC debug info, so GCC shouldn't play role (except if there's > memory trashing) > > > Example type mismatch (from your previous debugging code): > > > > Copyfield list mismatch (4<>1): enum > > :__unnamed --invalid--* > hmm this sounds like C++ code... which winedbg doesn't currently handle > properly... there's also lots of unsupported features in MSC debug info > loading (see debugger/msc.c for an outlook) > (could you anyway tell me the def of CDecBorderDialogBarPage) > > this will be rather hard to debug and fix remotely... > > > I also now only get this warning after the type mismatch warning. > > > > failure on _Bool:t(0,21)=@s8;-16; at ; > well, it seems we need to chew the ';' too (but this won't fix the issue > above) > add > if (*ptd->ptr++ != ';') return -1; > in the patch I already sent you (here's the whole modif) > > case '-': > if (DEBUG_PTS_ReadNum(ptd, &lo) == -1) { > DEBUG_Printf(DBG_CHN_MESG, "Should be a number...\n"); > return -1; > } > switch (lo) > { > case 1: new_dt = DEBUG_TypeInt; break; > case 7: new_dt = DEBUG_TypeShortUInt; break; > case 16: new_dt = DEBUG_TypeUSInt; break; > case 19: new_dt = DEBUG_TypeString; break; > default: > DEBUG_Printf(DBG_CHN_MESG, "Unsupported integral type (%d)\n", lo); > return -1; > } > if (*ptd->ptr++ != ';') return -1; > break; > > -- > --------------- > Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) > "The future will be better tomorrow", Vice President Dan Quayle > > >

Nov. 26, 2001

Re: ITypeInfo_fnGetContainingTypeLib

by lawson_whitney＠juno.com

On Sun, 25 Nov 2001, Ove Kaaven wrote: > I've explained it before on this list - you need to apply a typelib > refcounting patch, and there is one by Malte somewhere in the wine-patches Yes, I see you did, now I know to look for it. > archives. But since you ask, here is the refcounting pieces of the patch > we use in WineX: > Sorry, I thought that was in the cvs already. Thanks! Lawson

Nov. 25, 2001

Re: Crashing menus, event handling broken?

by Jukka Heinonen

Jukka Heinonen wrote: > It looks like the correct fix is much more simple than I > thought it would be: wineserver get_message handler just needs to > check that there are no pending cooked messages before returning > raw messages and some signaling magic must be added to > prevent wakeups for raw messages if a cooked message has been > queued. The above solution does not work. If menu is activated using keyboard shortcuts we can still have one broken cooked message queued. As far as I can see, mouse message handling works in normal cases, but when capture is enabled, Wine has at least these problems: - When capture is enabled, capturing window can receive nonclient messages for clicks processed before capture was enabled. - Subwindows of captured window can receive mouse messages queued before capture was enabled. - After capture is disabled, old capturing window can still receive captured messages queued before capture was disabled. - MSDN page about SetCapture describes that capturing window receives mouse messages only when mouse is over the capturing window (This likely includes child windows. MSDN explicitly says that this excludes child windows that belong to other threads.) or when mouse button is pressed over capturing window and button is help down (this means all windows owned by current process no matter which thread owns them). If I understand it correctly, Wine capturing doesn't work with multiple threads and it doesn't care whether mouse buttons are pressed or not. -- Jukka Heinonen <http://www.iki.fi/jhei/>

Nov. 25, 2001

Re: ITypeInfo_fnGetContainingTypeLib

by Ove Kaaven

On Sat, 24 Nov 2001 lawson_whitney(a)juno.com wrote: > Anyone like to take a swat at this? I've explained it before on this list - you need to apply a typelib refcounting patch, and there is one by Malte somewhere in the wine-patches archives. But since you ask, here is the refcounting pieces of the patch we use in WineX: Index: typelib.c =================================================================== RCS file: /cvsroot/winex/wine/dlls/oleaut32/typelib.c,v retrieving revision 1.1.1.17 diff -u -r1.1.1.17 typelib.c --- typelib.c 2001/10/28 14:14:58 1.1.1.17 +++ typelib.c 2001/11/25 09:05:56 @@ -1739,6 +1743,7 @@ pcx->pTblDir->pTypeInfoTab.offset+count*sizeof(tiBase)); /* this is where we are coming from */ ptiRet->pTypeLib = pLibInfo; + ITypeLib2_AddRef((ITypeLib2 *)pLibInfo); ptiRet->index=count; /* fill in the typeattr fields */ FIXME("Assign constructor/destructor memid\n"); @@ -2876,6 +2881,7 @@ } *ppTypeInfoImpl = (ITypeInfoImpl*)ITypeInfo_Constructor(); (*ppTypeInfoImpl)->pTypeLib = pTypeLibImpl; + ITypeLib2_AddRef((ITypeLib2 *)pTypeLibImpl); (*ppTypeInfoImpl)->index = i; (*ppTypeInfoImpl)->Name = TLB_MultiByteToBSTR( pOtherTypeInfoBlks[i].name_offs + @@ -4198,7 +4204,7 @@ if(!pRefType) FIXME("Can't find pRefType for ref %lx\n", hRefType); if(pRefType && hRefType != -1) { - ITypeLib *pTLib; + ITypeLib *pTLib = NULL; if(pRefType->pImpTLInfo == TLB_REF_INTERNAL) { int Index; @@ -4237,6 +4243,8 @@ result = ITypeLib2_GetTypeInfo(pTLib, pRefType->index, ppTInfo); } + if (pTLib != NULL) + ITypeLib2_Release(pTLib); } }

Nov. 25, 2001

Re: ITypeInfo_fnGetContainingTypeLib

by lawson_whitney＠juno.com

On Sun, 25 Nov 2001, Huw D M Davies wrote: > I'd 'like' to see the typelib trace, so if you could send me that I'd be > grateful. > > Thanks, > Huw. > Maybe not. I seem to have current cvs + install.diff (http://www.winehq.com/~ovek/install.diff) and it does crash in proxy.c... I hope it is useful, or at least not too pernicious. Lawson

Nov. 25, 2001

Re: ITypeInfo_fnGetContainingTypeLib

by lawson_whitney＠juno.com

On Sun, 25 Nov 2001, Huw D M Davies wrote: > I'd 'like' to see the typelib trace, so if you could send me that I'd be > grateful. > > Thanks, > Huw. > No worry! I can alwaus make another one. Lawson

Nov. 25, 2001

Re: ttydrv fix (adds missing ShowWindow function)

by lawson_whitney＠juno.com

On Thu, 22 Nov 2001 lawson_whitney(a)juno.com wrote: > Is it asking too much to use diff -u? Would you like to get patches > from all over the world against who knows which version of wine in > random formats? I think -u is the only format suitable for an > open-source project. > > Regards, > I am not the Patch Police, you don't have to hide. I was just trying to help, in my usual inept fashion. Why don't you make up the patch as a diff -u and submit it again? Oh, please don't forget to include a ChangeLog entry (to go eventually to <wine>/ChangeLog). Lawson Constants aren't, and variables won't. ---oof---

Nov. 25, 2001

Re: ITypeInfo_fnGetContainingTypeLib

by Huw D M Davies

On Sat, Nov 24, 2001 at 06:58:47PM -0500, lawson_whitney(a)juno.com wrote: > Good day! > > Anyone like to take a swat at this? I don't normally shy from a page > fault, but frankly, ICOM confuses me. Anyway, maybe Ove can spot it in > a second. If I have to do it it may take weeks. Backtrace attached. > Wineconsole seems to be working nicely, as long as the resolution is > good and high. > > I wanted to include a typelib trace, but that crashes at an earlier > spot. I haven't really looked at that one yet; I can send it along if > anyone is interested. At least Wine is starting to get its teeth into > InstallSh**** and its confounded IKernel.exe. I'd 'like' to see the typelib trace, so if you could send me that I'd be grateful. Thanks, Huw.

Nov. 25, 2001

ITypeInfo_fnGetContainingTypeLib

by lawson_whitney＠juno.com

Good day! Anyone like to take a swat at this? I don't normally shy from a page fault, but frankly, ICOM confuses me. Anyway, maybe Ove can spot it in a second. If I have to do it it may take weeks. Backtrace attached. Wineconsole seems to be working nicely, as long as the resolution is good and high. I wanted to include a typelib trace, but that crashes at an earlier spot. I haven't really looked at that one yet; I can send it along if anyone is interested. At least Wine is starting to get its teeth into InstallSh**** and its confounded IKernel.exe. Regards Lawson ---oof---

Nov. 24, 2001