http://bugs.winehq.org/show_bug.cgi?id=3822
------- Additional Comments From jbdubbs(a)gmail.com 2006-08-02 18:46 -------
Gotcha, sorry for the confusion. This basically means that Wine isn't
conforming to Free Desktop standards for system applets, correct?
--
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=4512
------- Additional Comments From ploujj(a)gmail.com 2006-08-02 16:28 -------
It seems that _almost_ none of the wine output I posted so far actually relates
to the problem since I see the same thing when running Unreal without problems
(in singleplayer):
$ ~/apps/wine-0.9.7/wine ~/.wine/drive_c/UnrealGold/System/Unreal.exe
fixme:process:GetProcessWorkingSetSize (0xffffffff,0x55bff568,0x55bff560): stub
err:ole:CoGetClassObject class {92fa2c24-253c-11d2-90fb-006008a1f441} not registered
err:ole:CoGetClassObject no class object {92fa2c24-253c-11d2-90fb-006008a1f441}
could be created for for context 0x1
fixme:ole:CoCreateInstance no classfactory created for CLSID
{92fa2c24-253c-11d2-90fb-006008a1f441}, hres is 0x80040154
err:ole:CoGetClassObject class {d8f1eee0-f634-11cf-8700-00a0245d918b} not registered
err:ole:CoGetClassObject no class object {d8f1eee0-f634-11cf-8700-00a0245d918b}
could be created for for context 0x1
fixme:ole:CoCreateInstance no classfactory created for CLSID
{d8f1eee0-f634-11cf-8700-00a0245d918b}, hres is 0x80040154
fixme:keyboard:RegisterHotKey (0x1002a,49218,0x00000001,27): stub
fixme:keyboard:RegisterHotKey (0x1002a,49219,0x00000001,9): stub
fixme:keyboard:RegisterHotKey (0x1002a,49220,0x00000002,27): stub
fixme:keyboard:RegisterHotKey (0x1002a,49221,0x00000002,9): stub
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x559ac798)->((nil),00000008)
This error:
fixme:winsock:NtStatusToWSAError Status code c0000024 converted to DOS error code 6
appears quite a lot some time before Unreal crashes, and since it seems like a
network error, I don't think its related to the crash in question.
--
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=4515
------- Additional Comments From volker(a)dirr-computer.de 2006-08-02 16:26 -------
if i run it with "virtual desktop" of course a window open. but the relay log
just grow again up to ~6MB. The last lines are the same as without "virtual
desktop". if i click into the black opend window the relay log grows again a few KB.
i was to silly to do changes with the regedit.
so i open ./wine/userdef.reg and attached the following:
[Software\\Wine\\Debug]
"RelayExclude"="RtlEnterCriticalSection;RtlLeaveCriticalSection;_EnterSysLevel;_LeaveSysLevel;_CheckNotSysLevel;NtCurrentTeb;LdrAccessResource;RtlUpperChar;kernel32.94;kernel32.97;kernel32.98;TlsGetValue"
(so i changed your first line, because he other lines in this file look like the
same)
after saving the file i can not the any changes with regedit.
but afer opening ./wine/userdef.reg again i saw that wine added a number:
[Software\\Wine\\Debug] 1139436308
i donŽt know if i done it like you want. otherwise please explain me a little
more detailed.
i run a relay with "virtual desktop", the changed userdef.reg and with win98.
i attach the log-file.
volker
--
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=4512
------- Additional Comments From ploujj(a)gmail.com 2006-08-02 16:22 -------
This seems to happen only in online games. I have been playing the Return to
NaPali campaign for quite some time and it runs flawless.
Please let me know what other info I can provide to narrow this problem down.
--
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=4521
Summary: hl2 and Engine Error
Product: Wine
Version: CVS
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: b.buschinski(a)web.de
wine: CVS (20060208)
I am unabled to start hl2
with other Vertex shader than "emulated"
it crashed with "none" and "hardware"
with a message box
"Engine Error - failed to lock vertex buffer in CMeshDX8::LockVertexBuffer"
I start hl2 with
-fullscreen -width 1024 -height 768 -novid -map_background none -dxlevel 70
the -dxlevel doesnt change anything, also tried 80 90 and 91
crash the same way
when I try to start a new game with "emulated" vertex shader
bug http://bugs.winehq.org/show_bug.cgi?id=4497
apaers
when I try to start hl2 without
-map_background none
it crashs always with
"Engine Error - failed to lock vertex buffer in CMeshDX8::LockVertexBuffer"
in vertex shader modes
--
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=4436
------- Additional Comments From J.A.Gow(a)furrybubble.co.uk 2006-08-02 13:49 -------
Since then I have been doing some more digging into the problem and have come up
with a test that triggers the bugs: i.e. passes on Windows and fails on Wine
(latest CVS). Looking at the failure mode I feel that it has the potential to
break a _lot_ of apps.
It is as I thought that there is some issue with the object destructor for the
storage object being called and not actually releasing the object. I have
attached the complete patch to the tests for storage32 to this message if anyone
could try it I would be grateful, but I will just describe some of the reasoning
behind it first.
It seems that the problem is not the grfMode with which the file is opened, but
a reference counting method used within storage32. A call to the destructor of
the storage object is not destroying the object - with it left open the error
appears when a subsequent call to open the storage object fails with access
issues because the previous one is left open. So, I introduced this test that
exactly mimics the behaviour of the app. To do this, I needed a storage object
that contained a stream, so I wrote code in the appropriate conformance test
module to create one:
r = StgOpenStorage( filename, NULL, STGM_TRANSACTED | STGM_WRITE |
STGM_SHARE_DENY_WRITE, NULL, 0, &stg);
ok(r==S_OK, "StgOpenStorage failed\n");
if(stg)
{
static const WCHAR stmname[] = { 'w','i','n','e','t','e','s','t',0};
IStream *stm = NULL;
r = IStorage_CreateStream( stg, stmname, STGM_WRITE | STGM_SHARE_EXCLUSIVE,
0, 0, &stm );
ok(r == S_OK, "CreateStream should succeed\n");
if(stm) {
r=IStorage_Commit(stg,STGC_DEFAULT);
ok(r==S_OK, "StorageCommit failed\n");
}
// Windows reference counting seems different....
r = IStorage_Release(stg);
ok(r == 0, "wrong ref count"); printf("- ref count = %lx\n",r);
if(r) {
r = IStorage_Release(stg);
ok(r == 0, "wrong ref count"); printf(" - ref count = %lx\n",r);
}
}
It was here where I got the surprise! I expected this code to work on both Wine
and Windows, so the next part of the patch could trigger the bug. However I
found that on Windows, the first call to IStorage_Release returns zero, and the
storage object is destroyed. Under Wine however, the first call to
IStorage_Release returns 1 but does not destroy the object - the second call to
IStorage_Release returns zero and destroys the object. It appears that Windows
takes no notice of reference counts when the IStorage destructor is called! I
only discovered this because in the original test code I had two calls to
IStorage_Release straight after each other without the if(r) test: and although
it worked on Wine it segfaulted on Windows due to the 'stg' object being
destroyed on the first call. This proved the difference in behaviour.
Now on to the second part of the test, that attempted to re-open the closed
storage object, then open the stream within it:
/* Easy-PC test 2 - this looks for the OpenStream mode check. Fails under
Wine */
r = StgOpenStorage( filename, NULL, 0x00010020, NULL, 0, &stg);
ok(r==S_OK, "StgOpenStorage failed\n");
if(stg)
{
static const WCHAR stmname[] = { 'w','i','n','e','t','e','s','t',0};
IStream *stm = NULL;
r = IStorage_OpenStream( stg, stmname, 0,
STGM_SHARE_EXCLUSIVE|STGM_READWRITE, 0, &stm );
ok(r == S_OK, "OpenStream should succeed - "); printf("rc from
OpenStream : %lx\n",r);
r = IStorage_Release(stg);
ok(r == 0, "wrong ref count\n");
}
Again, this works on Windows, but the OpenStream call fails with an access
denied error on Wine. This is the exact mode of the bug in the app.
Could one of the ole32 developers please contact me: I am happy to work with
them to resolve this problem as I need this app to work under Wine, but not
being a Windows programmer I am not fully familiar with the storage API. In the
meantime I will continue my investigation and see if I can fix this directly,
but I am sure it will happen sooner if I could work directly with the ole32
developer.
--
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=4436
------- Additional Comments From J.A.Gow(a)furrybubble.co.uk 2006-08-02 13:47 -------
Created an attachment (id=1863)
--> (http://bugs.winehq.org/attachment.cgi?id=1863&action=view)
Additional conformance tests that trigger bug in IStorage implementation
This is a patch to the tests in ole32/tests/storage32.c that will trigger the
bug. Please see my latest comments appended to this bug for more details. Patch
has been submitted for inclusion in CVS.
--
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=4510
jjk3(a)msstate.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #1847 is|0 |1
obsolete| |
------- Additional Comments From jjk3(a)msstate.edu 2006-08-02 13:05 -------
Created an attachment (id=1862)
--> (http://bugs.winehq.org/attachment.cgi?id=1862&action=view)
config.log after patch
--
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.