I have some weeks before reported, FlashFXP v3.02 loops with a message-loop in listview.c after login. It does this in Odin and in Wine. In Odin it stops in smaller time (deep 1000). Wine has a bigger stack, and so needs wine more time for this, bat I can see in the loog, the args for the function are more and more locatet at lower stack adresses. I have written this workarout for testing this problem in wine and in odin. with this FlashFXH 3.02 will display the contence of the server dir very fast at both environment. In the log I can see, that the message-loop was reported and stopped. I thing, we need a flag inside any item to report every function, that can called recursive, this item is in work (function-separart, or global ?), that can stop recursions of this type in the future or many programms. I have also found this try does also helps Agent 2.0 in the groups->defailt propertys (only odin-tested). This does also every crashs in earlyer builds with stack overflow in odin.
Dietrich
Index: wine/dlls/comctl32/listview.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/listview.c,v retrieving revision 1.406 diff -u -r1.406 listview.c --- wine/dlls/comctl32/listview.c 25 Mar 2005 20:49:00 -0000 1.406 +++ wine/dlls/comctl32/listview.c 29 Mar 2005 16:31:48 -0000 @@ -139,6 +139,7 @@ * WM_CREATE does not issue WM_QUERYUISTATE and associated registry * processing for "USEDOUBLECLICKTIME". */ +#define __T__
#include "config.h" #include "wine/port.h" @@ -7050,10 +7051,23 @@ * SUCCESS : TRUE * FAILURE : FALSE */ +#ifdef __T__ +static int zIndex = -2; +typedef struct { + PVOID lTol; + HWND cHwnd; + HWND cHwndParent; + INT cItem; + } SetItemStateLink, *PSetItemStateLink; +#endif static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *infoPtr, INT nItem, const LVITEMW *lpLVItem) { BOOL bResult = TRUE; LVITEMW lvItem; +#ifdef __T__ + int saveLastError = GetLastError(); + SetItemStateLink cTol = { NULL, infoPtr->hwndSelf, infoPtr->hwndNotify, nItem}; +#endif
lvItem.iItem = nItem; lvItem.iSubItem = 0; @@ -7062,6 +7076,34 @@ lvItem.stateMask = lpLVItem->stateMask; TRACE("lvItem=%s\n", debuglvitem_t(&lvItem, TRUE));
+#ifdef __T__ + if (-2 == zIndex) + { + zIndex = TlsAlloc(); + SetLastError(saveLastError); + } /* endif */ + if (zIndex >= 0) + { + cTol.lTol = TlsGetValue(zIndex); + if (cTol.lTol < (PVOID)&cTol) + { + cTol.lTol = NULL; + } /* endif */ + SetLastError(saveLastError); + if (cTol.lTol + && (((PSetItemStateLink)cTol.lTol)->cHwnd == infoPtr->hwndSelf) + && (((PSetItemStateLink)cTol.lTol)->cHwndParent == infoPtr->hwndNotify) + && (((PSetItemStateLink)cTol.lTol)->cItem == nItem)) + { + TRACE_(listview)("(DT) Hwnd:%x,%x Parent:%x,%x Item:%d,%d, stop the recursion\n", infoPtr->hwndSelf, ((PSetItemStateLink)cTol.lTol)->cHwnd, + infoPtr->hwndNotify, ((PSetItemStateLink)cTol.lTol)->cHwndParent, + nItem, ((PSetItemStateLink)cTol.lTol)->cItem); + return TRUE; + } + TlsSetValue(zIndex,(LPVOID)&cTol); + SetLastError(saveLastError); + } +#endif if (nItem == -1) { /* apply to all items */ @@ -7070,6 +7112,14 @@ } else bResult = LISTVIEW_SetItemT(infoPtr, &lvItem, TRUE); +#ifdef __T__ + if (zIndex >= 0) + { + saveLastError = GetLastError(); + TlsSetValue(zIndex,(LPVOID)cTol.lTol); + SetLastError(saveLastError); + } +#endif
/* *update selection mark
On Tue, Mar 29, 2005 at 06:52:07PM +0200, Dietrich Teickner wrote:
I have some weeks before reported, FlashFXP v3.02 loops with a message-loop in listview.c after login. It does this in Odin and in Wine. In Odin it stops in smaller time (deep 1000). Wine has a bigger stack, and so needs wine more time for this, bat I can see in the loog, the args for the function are more and more locatet at lower stack adresses. I have written this workarout for testing this problem in wine and in odin. with this FlashFXH 3.02 will display the contence of the server dir very fast at both environment. In the log I can see, that the message-loop was reported and stopped. I thing, we need a flag inside any item to report every function, that can called recursive, this item is in work (function-separart, or global ?), that can stop recursions of this type in the future or many programms. I have also found this try does also helps Agent 2.0 in the groups->defailt propertys (only odin-tested). This does also every crashs in earlyer builds with stack overflow in odin.
Dietrich,
You need to create a small example app that exhibits this behaviour such that it crashes on Wine/Odin, but runs in Windows. As things stand, I can not test with either app since they don't install under Wine. In any event, a small example app would be better, since the source would be available too.