http://bugs.winehq.org/show_bug.cgi?id=5668
------- Additional Comments From stefandoesinger(a)gmx.at 2006-20-08 16:15 -------
Some suggestions:
-> Can you check if This->ddraw->d3ddevice is != NULL in that function?
-> Add a NULL check for lpDirect3DDevice3 in
IDirect3DMaterialImpl_GetHandle(material.c)
return DDERR_INVALIDPARAMS if the device is 0 in any case. I suspect that the
app calls SetBackground without initializing a device before. It passes a
random material handle because it can't have one without a device.
--
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=4093
marcus(a)jet.franken.de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marcus(a)jet.franken.de
------- Additional Comments From marcus(a)jet.franken.de 2006-20-08 16:15 -------
i spent quite some time trying to find out why this happens.
The pattern I see is:
- multiple threads doing IDsDriverBufferImpl_GetPosition()
They try to enter the critical section and have RtlpWaitForCriticalSection
in their backtrace.
- 2 of them have additional in the stacktrace a DSDB_MMAPCopy()
Somehow the piece of code doing this gets injected on top of the previous
stack? It is unclear how this is done, but it might be ALSA specific.
And yes, I have added some debug code that show this is the case (and not
just some random stack corruption).
What I suspect is that one the calls has just acquired the lock, but
the pushed on top instruction flow tries to lock it again, but fails.
Sample gdb bt excerpt:
(gdb) bt
#0 0x7bc287b8 in RtlpWaitForCriticalSection (crit=0x181244) at
critsection.c:64
#1 0x7bc28c99 in RtlEnterCriticalSection (crit=0x181244) at critsection.c:508
#2 0x612cdb03 in DSDB_MMAPCopy (pdbi=0x181238, mul=1) at audio.c:3120
#3 0x6136cf6e in snd_output_buffer_open () from /usr/lib/libasound.so.2
...
#22 0x7bc5551b in wine_server_call (req_ptr=0x181244) at server.c:324
#23 0x612cd775 in IDsDriverBufferImpl_GetPosition (iface=0x181238,
lpdwPlay=0x34fd58, lpdwWrite=0x34fd54) at audio.c:3378
#24 0x605d5488 in DSOUND_PrimaryGetPosition (device=0x1709d8,
playpos=0x34fd58, writepos=0x34fd54) at primary.c:296
#25 0x605bd0ad in IDirectSoundBufferImpl_GetCurrentPosition (iface=0x3490028,
playpos=0x34fd90, writepos=0x0) at buffer.c:472
#0 0x7bc287b8 in RtlpWaitForCriticalSection (crit=0x181244) at
critsection.c:64
#1 0x7bc28c99 in RtlEnterCriticalSection (crit=0x181244) at critsection.c:508
#2 0x612cdb03 in DSDB_MMAPCopy (pdbi=0x181238, mul=1) at audio.c:3120
#3 0x6136cf6e in snd_output_buffer_open () from /usr/lib/libasound.so.2
...
#59 0x7bc28725 in RtlpWaitForCriticalSection (crit=0x181244) at
critsection.c:64
#60 0x7bc28c99 in RtlEnterCriticalSection (crit=0x181244) at critsection.c:508
#61 0x612cd775 in IDsDriverBufferImpl_GetPosition (iface=0x181238,
lpdwPlay=0x616c2a18, lpdwWrite=0x616c2a14) at audio.c:3378
#62 0x605d3620 in DSOUND_timer (timerID=1, msg=4294967292, dwUser=1509848,
dw1=4294967292, dw2=4294967292) at mixer.c:963
#63 0x6062944c in TIME_MMSysTimeThread (arg=0x6067bc20) at time.c:95
#64 0x7b88cd38 in THREAD_Start (ptr=0xfffffffc) at thread.c:76
The threads might have received SIGUSR1 calls? I looked at one of the inner
RtlpWaitForCritSections and $eax is -4 (-EINTR) which might suggest
interruption due to signal.
--
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=4273
------- Additional Comments From gelsonluz(a)click21.com.br 2006-20-08 15:55 -------
Tested again with wine 0.9.19. Bug not solved yet
--
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=6014
Summary: possible race condition in Robert E Lee Civil War
General installer
Product: Wine
Version: CVS
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ead1234(a)hotmail.com
When trying to install Robert E Lee, Civil War General I get the following error
in my console.
wine setup.exe
Terminated
wine setup.exe
Terminated
Then the 3rd try the installer starts with an ole error and then installs
completely.
wine setup.exe
err:ole:CoUninitialize Mismatched CoUninitialize
--
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=5703
------- Additional Comments From xerox_xerox2000(a)yahoo.co.uk 2006-20-08 15:41 -------
well, i already did that regression test. It broke during the ddraw-rewrite, but
the crash was different then. Just after your ddraw rewrite was merged , it
really crashed in ddraw itself, but i forgot where exactly. However, in later
wine-versions this issue seemed to be fixed,but the it crashed in a different
way (in gdi) so now i don't know anymore if this is because your rewrite reveals
another bug in gdi, or whatever. Fact is it doesn't run anymore, but the cause
is difficult to find...
--
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=5365
tony.lambregts(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|NoAppDBEntry |
--
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=5589
------- Additional Comments From stefandoesinger(a)gmx.at 2006-20-08 15:36 -------
Did you try running wineprefixcreate after the update? There have been dinput
patches which need some new registry keys which are created when dinput is
registered. If wineprefixcreate doesn't help, can you try to remove ~/.wine ?
If the ddraw bug is fixed can you close this bug and open a new bug for the
dinput issue if it isn't fixed with re-createing the wine directory?
--
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=5730
------- Additional Comments From stefandoesinger(a)gmx.at 2006-20-08 15:31 -------
can you attach a +ddraw,+d3d7 log? It doesn't have to be long, just up to the
first point where the bug can be seen.
--
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.