Eric Pouech pouech-eric@wanadoo.fr wrote:
To: Anish Mistry mistry.7@osu.edu Cc: wine-devel@winehq.org Subject: Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation
and if you remove the entire line (if (!is_version_nt()) access = TIMER_ALL_ACCESS;)? A+
--__--__--
That doesn't fix the problem here. Still the same trace response... I haven't run it enough times to see if it will still occasionally work with that line altered or removed... I know it does work (without any changes from the version in CVS) about 5% of the time.
Jonathan Gevaryahu lord_nightmare@users.sf.net
Jonathan Gevaryahu a écrit :
Eric Pouech pouech-eric@wanadoo.fr wrote:
To: Anish Mistry mistry.7@osu.edu Cc: wine-devel@winehq.org Subject: Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation
and if you remove the entire line (if (!is_version_nt()) access = TIMER_ALL_ACCESS;)? A+
--__--__--
That doesn't fix the problem here. Still the same trace response... I haven't run it enough times to see if it will still occasionally work with that line altered or removed... I know it does work (without any changes from the version in CVS) about 5% of the time.
hmm it don't see where this could come from could someone of you try to apply the patch in parts (semaphore, event, timer, mutex), just to narrow a bit where this could come from A+
Eric Pouech wrote:
Jonathan Gevaryahu a écrit :
Eric Pouech pouech-eric@wanadoo.fr wrote:
To: Anish Mistry mistry.7@osu.edu Cc: wine-devel@winehq.org Subject: Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation
and if you remove the entire line (if (!is_version_nt()) access = TIMER_ALL_ACCESS;)? A+
--__--__--
That doesn't fix the problem here. Still the same trace response... I haven't run it enough times to see if it will still occasionally work with that line altered or removed... I know it does work (without any changes from the version in CVS) about 5% of the time.
hmm it don't see where this could come from could someone of you try to apply the patch in parts (semaphore, event, timer, mutex), just to narrow a bit where this could come from A+
Is anyone still looking into this?
I'm seeing the same problem here (below messages repeated and 100% CPU usage) on RH 9 with the direct sound regression test and some games.
0009: select( flags=4, cookie=0x4084f930, timeout=0, handles={0x64} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x4084f930, timeout=0, handles={0x64} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x4084f930, timeout=0, handles={0x64} ) 0009: select() = ACCESS_DENIED
Is anyone still looking into this?
I'm seeing the same problem here (below messages repeated and 100% CPU usage) on RH 9 with the direct sound regression test and some games.
does this (new) patch help ? A+
Eric Pouech wrote:
Is anyone still looking into this?
I'm seeing the same problem here (below messages repeated and 100% CPU usage) on RH 9 with the direct sound regression test and some games.
does this (new) patch help ?
Well, i don't know if it fixes their problem but at least it makes Quicktime stop looping (wineserver and a wine-preloader process are maxing out the CPU) for me. Now i get the stupid "make the whole display black" Quicktime thingy and then it crashes: wine: Unhandled exception (thread 001d), starting debugger... WineDbg starting on pid 0x1c Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:00000000 ESP:7791fdd5 EBP:7791fe34 EFLAGS:00010202( - 00 - -RI1) EAX:6e4f8a00 EBX:00000000 ECX:00000000 EDX:77c86284 ESI:7791fe58 EDI:7791fdf5 Stack dump: 0x7791fdd5: 6e31fbec 00000000 06000000 00000002 0x7791fde5: 7174696d 7791feb0 0046d24e 00000000 0x7791fdf5: bb7791fe 0077c511 00030000 05000000 0x7791fe05: 00c00000 00004000 1f000000 00000000 0x7791fe15: 00000000 f8030000 b97791fd 947791f9 0x7791fe25: 587791fe 686e35c6 006e43ad a0000000 Backtrace: =>1 0x00000000 (0x7791fe34) 2 0x00448e51err:dbghelp_msc:pdb_process_internal -Unable to peruse .PDB file C:\qtml\buildresults\nosym\QuickTimePlayer.pdb in quicktimeplayer (+0x48e51) (0x7791fea0) 3 0x0046d32e EntryPoint+0xe0 in quicktimeplayer (0x7791ff2c) 4 0x77baf49b start_process+0xc3(arg=0x0) [/home/michi/work/wine/dlls/kernel/process.c:1046] in kernel32 (0x7791fff4) 5 0xb7fcb69d wine_pthread_abort_thread+0x29(status=0x0) [/home/michi/work/wine/libs/wine/port.c:85] in libwine.so.1 (0x00000000) 0x00000000: addb %al,0x0(%eax) Wine-dbg>
Hope this helps (if it's related).
bye michael
On Thu, 30 Dec 2004 15:25:20 +0100, Michael Stefaniuc wrote:
Now i get the stupid "make the whole display black" Quicktime thingy
That's a bug in DirectDraw, we have a bad hack in CrossOver for it but it needs to be fixed properly.
Word on the street is that we need an implementation of the DirectDraw clipper, but I have no idea if that's correct or if so, how much of it we need.
thanks -mike
Word on the street is that we need an implementation of the DirectDraw clipper, but I have no idea if that's correct or if so, how much of it we need.
Last time I checked, it was not clipper related at all. It's basically (from what I remember - I could be wrong) QuickTime that displays on the desktop window using DirectX (just at the start, after it uses clipper and windows).
This means that if we want to make this work, we need first to lock the X server then take a screenshot of the root window then put it in the buffer to give back to QT to draw on it and then re-copy this in what is currently the black window and finally unlock the X server... In other means a bad hack :-)
In my opinion, the cleanest would just to not support at all 'window-less' DirectX as the only one using it is QT and it uses it badly :-)
Lionel
-
Eric Pouech -
Jonathan Gevaryahu -
Lionel Ulmer -
Michael Stefaniuc -
Mike Hearn -
Robert Reif