http://bugs.winehq.org/show_bug.cgi?id=2127
Summary: WriteFile fails on threaded applications
Product: Wine
Version: 20040309
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-kernel
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: tronb(a)bluesquirrel.com
Tested on: Fedora Core 1 and Fedora test 1.90
Version: Latest rpm and build from source 20040309
In threaded applications, which use CreateFile, WriteFile, CloseHandle heavily
(logging) in a threaded application, the WriteFile will fail because of a bad
fd even when the sequence (CreateFile, WriteFile, CloseHandle) is protected as
a critical section.
Test Code:
#include "stdafx.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
int Test();
DWORD WINAPI AThread( LPVOID lpParameter );
int Log(const char * stuff);
// The one and only application object
CWinApp theApp;
using namespace std;
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
int nRetCode = 0;
// initialize MFC and print and error on failure
if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0))
{
// TODO: change error code to suit your needs
_tprintf(_T("Fatal Error: MFC initialization failed\n"));
nRetCode = 1;
}
else
{
Test();
}
return nRetCode;
}
int Test()
{
#define NUM_THREADS 10
int ThreadNo[NUM_THREADS];
HANDLE ThreadHandles[NUM_THREADS];
//Start 10 threads
for(int i=0;i<NUM_THREADS;i++)
{
ThreadNo[i] = i;
ThreadHandles[i] = CreateThread(NULL, 0, AThread, &(ThreadNo
[i]), 0, NULL);
if (ThreadHandles[i] == NULL)
printf("CreateThread failed to create thread %d with
GetLastError:%d\n", i, GetLastError());
}
printf("Created %d Threads\n", NUM_THREADS);
DWORD result = WaitForSingleObject(ThreadHandles[0], 2L*60L*1000L);
if (result == WAIT_TIMEOUT)
printf("Timed out waiting for thread 0\n");
return(i);
}
DWORD WINAPI AThread( LPVOID lpParameter )
{
char buffer[100];
while(1)
{
int *lpint = (int*)lpParameter;
sprintf(buffer, "This is some stuff from thread %d\n", *lpint);
Log(buffer);
}
}
int Log(const char * stuff)
{
HANDLE hMutex = CreateMutex(NULL, TRUE, NULL);
if (hMutex == 0)
printf("Mutex failed\n");
//Wait for 5 seconds
DWORD dwWaitResult = WaitForSingleObject( hMutex, 5000L );
if (dwWaitResult == WAIT_TIMEOUT)
printf("Wait timed out\n");
if (dwWaitResult == WAIT_ABANDONED)
printf("Wait abandoned\n");
HANDLE hFile = CreateFile("C:\\TESTLOG.LOG", FILE_WRITE_DATA,
FILE_SHARE_WRITE, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if (hFile == INVALID_HANDLE_VALUE)
{
printf("CreateFile Failed with GetLastError of %d\n",
GetLastError());
}
DWORD NewLoc = SetFilePointer (hFile, 0, NULL, FILE_END);
DWORD bytes_written;
BOOL write_file_result = WriteFile(hFile, stuff, (DWORD)strlen(stuff),
&bytes_written, NULL);
if (write_file_result == 0)
{
printf("WriteFile Failed with GetLastError of %d\n",
GetLastError());
}
if (CloseHandle(hFile) == 0)
printf("CloseHandle Failed with %d\n", GetLastError());
BOOL release_mutex_result = ReleaseMutex(hMutex);
if (release_mutex_result == 0)
printf("ReleaseMutex failed with %d\n", GetLastError());
return(0);
}
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2124
------- Additional Comments From mandreiana(a)yahoo.com 2004-25-03 04:46 -------
thank you. I have limited traffic and cannot checkout wine cvs.
Now I got a Fedora Core rpm from newrpms site, saw a message that their build
also solved security patch problem (how? don't know), and the application works
again.
Wierd, it's the same wine version, maybe compiled different.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2126
Summary: fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal
yet.
Product: Wine
Version: 20040309
Platform: PC
URL: http://urania.ouvaton.org/wine.png
OS/Version: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: wine-binary
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: lenaig(a)wanadoo.fr
Hi,
I am running a Debian unstable under my laptop.
I am trying to run wine with Steam, to be able to play network games as DoD or
CS ...
When i am running wine i have this following error :
tst@localhost:~$ wine Jeux/SteamInstall.exe
ReadStyleSheet: missing style number
Last token read was "}" near line 2, position 22.
fixme:shell:Stream_WriteLocationInfo writing empty location info
err:menubuilder:InvokeShellLinker failed to extract icon.
fixme:shell:Stream_WriteLocationInfo writing empty location info
err:menubuilder:WinMain failed to build menu item for C:\Windows\Start
Menu\Programs\Valve\Steam\Steam Subscriber Agreement.lnk
fixme:shell:Stream_WriteLocationInfo writing empty location info
err:menubuilder:InvokeShellLinker failed to extract icon.
fixme:shell:Stream_WriteLocationInfo writing empty location info
err:menubuilder:InvokeShellLinker failed to extract icon.
fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x8000
fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.
You can exactly what happen there : http://urania.ouvaton.org/wine.png
Steam stop downloading after 26% ...
What can i do to help you resolving this problem ?
Thx
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=881
------- Additional Comments From fommil(a)yahoo.ie 2004-24-03 15:40 -------
more info:
i am using blackbox, and, more importantly... i have a workaround!
i have bbkeys installed which allows me to use keystrokes as macros for WM
operations. i have a keystroke defined to switch between virtual desktops. if i
switch to another desktop and then back to the wine one, the X cursor disappears
in the wine fullscreen! :-D
i am happy enough with this workaorund for now, but i think the bug should
remain open anyway.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2124
tony_lambregts(a)telusplanet.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |regression
------- Additional Comments From tony_lambregts(a)telusplanet.net 2004-24-03 12:13 -------
If this used to work then it is a regression the way to fix it is to find the
patch that broke it using regression testing as outlined here.
http://www.winehq.org/site/docs/wine-devel/cvs-regression
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2125
Summary: err:comboex:COMBOEX_FindItem COMBOBOXEX item structures
broken. Please report!
Product: Wine
Version: 20040309
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-misc
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mandreiana(a)yahoo.com
Getting this on an application
err:comboex:COMBOEX_FindItem COMBOBOXEX item structures broken. Please report!
So i'm reporting :)
Let me know if more info is needed
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2124
Summary: Windows socket error (10048) on API 'bind'
Product: Wine
Version: 20040309
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-net
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mandreiana(a)yahoo.com
A chat which used to work gives this dialog now
Windows socket error (10048) on API 'bind'
Then it continues, but it doesn't connect to local network.
The application can be downloaded from here
http://borgchat.softnews.ro/cgi-bin/download.pl?file=BORGChat
thanks
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=560
------- Additional Comments From tony_lambregts(a)telusplanet.net 2004-23-03 16:16 -------
Further investigation has lead me to believe that the front end for this does
not need to do much. All we really need is to call the Enter bug screen with
the bug_file_loc pointing to the the location of the app in th AppDB. For "The
Bat" it would look like this.
http://bugs.winehq.org/enter_bug.cgi?product=Wine&bug_file_loc=http%3A%2F%
2Fappdb.winehq.org%2Fappview.php%3FappId%3D68
(with out the line wrap)
The main problem is that the person entering the bug report has to have a
Bugzilla account and be log into it.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=2123
Summary: comctl32 tab.c size of the rect in the WM_DRAWITEM
message incorrect
Product: Wine
Version: 20040309
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: wine-winelib
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: r.kessel(a)metrodata.de
The screenoutput of the tab control is ugly, because the size of the draw area
(rcItem) given in the WM_DRAWITEM message is too large. Apps will usually clear
up the entire space, which clears the nicely painted borders as well.
I would suggest to add some lines in TAB_DrawItemInterior()
...
/*
* put together the DRAWITEMSTRUCT
*/
dis.CtlType = ODT_TAB;
dis.CtlID = id;
dis.itemID = iItem;
dis.itemAction = ODA_DRAWENTIRE;
dis.itemState = 0;
if ( iItem == infoPtr->iSelected )
dis.itemState |= ODS_SELECTED;
if (infoPtr->uFocus == iItem)
dis.itemState |= ODS_FOCUS;
dis.hwndItem = hwnd; /* */
dis.hDC = hdc;
CopyRect(&dis.rcItem,drawRect);
/*
* adjustments to the size of the user draw area should be added here
*/
dis.rcItem->left += 2;
dis.rcItem->top += 2;
dis.rcItem->right -= 2;
dis.itemData = infoPtr->items[iItem].lParam;
/*
* send the draw message
*/
SendMessageA( infoPtr->hwndNotify, WM_DRAWITEM, (WPARAM)id, (LPARAM)&dis );
...
The orginal windows dehaviour is quite complex. if the tab is not selected, the
user draw area is (left+4, top+2, right, bottom). If the tab is selected, the
user draw area is (left, top, right+4, bottom+4).
The main difference between the winelib tab-ctrl and the windows tab-ctrl is
that wine paints the frame BEFORE the WM_DRAWITEM message and Windows paints the
frame AFTER the tab content is draw by the WM_DrawITEM message. The windows
behaviour prevents that the frame got overwritten by the user drawings. This
could be am issue in cases where ownerdrawing is supported.
Additionally I have observed that the winelib tab draws the tab 10 points wider
than given in the tabsize (and the windows version).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.