http://bugs.winehq.org/show_bug.cgi?id=27626
Summary: Error after installing Call of Duty 4
Product: Wine
Version: 1.3.23
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: diego.viola(a)gmail.com
I get this error after I install Call of Duty 4 on Arch Linux x86-64. Please
see the attached files for the error. However the game runs great.
Wine version is 1.3.23.
Linux Kernel 2.6.39
nvidia 275.09.07-1
Sorry if this is a duplicate, couldn't find another bug id with the same
problem. I just want to help Wine and report issues, so it can hopefully be
fixed.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9220
Timo <t.sztyler(a)googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |t.sztyler(a)googlemail.com
--- Comment #25 from Timo <t.sztyler(a)googlemail.com> 2011-06-28 14:42:10 CDT ---
(In reply to comment #24)
> Still a bug in current wine?
I have installed FFVII on ArchLinux with Wine 1.3.23 + fglrx
The game starts, but the opening movie didn't come up - so the screen is black
(i have wait a few minutes) (Codec TrueMotion 2.0 didn't solve the problem for
me)
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=27614
Summary: [FreeBSD][eve
online][OOM][dll/iphlpapi/ifenum.c][enumIPAddresses()]
"Bad Handshake" bug
Product: Wine
Version: 1.3.23
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: pprocacci(a)gmail.com
Tested wine versions: 1.3.21 and 1.3.23
Attempting to log into the game "eve online" results in a "Bad Handshake"
error. I've narrowed down the problem to the following within the
enumIPAddresses routine in dll/iphlpapi/ifenum.c.
###########################################
do {
lastlen = ifc->ifc_len;
HeapFree(GetProcessHeap(), 0, ifc->ifc_buf);
if (guessedNumAddresses == 0)
guessedNumAddresses = INITIAL_INTERFACES_ASSUMED;
else
guessedNumAddresses *= 2;
ifc->ifc_len = sizeof(struct ifreq) * guessedNumAddresses;
ifc->ifc_buf = HeapAlloc(GetProcessHeap(), 0, ifc->ifc_len);
ioctlRet = ioctl(fd, SIOCGIFCONF, ifc);
} while ((ioctlRet == 0) && (ifc->ifc_len != lastlen));
###########################################
The above snippet of code loops endlessly until ioctl returns -1. The
statement "ifc->ifc_len != lastlen" is always true. This results in enormous
amounts of memory attempting to be allocated and then later used in ioctl.
Eventually the ioctl call will return -1, breaking the loop.
ERROR_INVALID_PARAMETER gets returned from this routine, and the proceeding
(proceeding proceeding) routine (GetAdaptersInfo) ends of returning
ERROR_OUTOFMEMORY.
############################################
ret = getIPAddrTable(&ipAddrTable, GetProcessHeap(), 0);
if (!ret)
ret = AllocateAndGetIpForwardTableFromStack(&routeTable, FALSE,
GetProcessHeap(), 0);
if (!ret)
table = getNonLoopbackInterfaceIndexTable();
if (table) {
<!--- snip ---->
}
else
ret = ERROR_OUTOFMEMORY;
############################################
I don't have a patch on hand or anything, but my debugging led me to the
information provided.
Hope this helps.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7411
GreatEmerald <pastas4(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pastas4(a)gmail.com
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=5535
--- Comment #74 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-06-27 10:41:21 CDT ---
(In reply to comment #73)
> Thanks for taking a look. What do you propose should happen to this bug? At the
> very least I suggest changing the title to reflect the GDI running out of
> handles issue that it seems to focus on (the current summary is far too vague).
I'm not sure. The GDI object limit is intentional I think. Trying to fill the
vidmem with surfaces is the game's doing, that won't be fixed.
I guess the way to fix this is to rewrite the GDI renderer not to use a DIB
section for every surface, only if it is a primary surface or the app calls
GetDC. On the other hand Alexandre once said the software ddraw implementation
should use gdi for blitting instead of its own implementations, which means we
need a DIB section everywhere.
Either way it is a tricky situation and would need a lot of work. Honestly I'd
prefer to ignore it and let people force the video memory size lower. We cannot
limit the vidmem for apps using ddraw.dll in general because some opengl apps
use ddraw to figure out how much video memory the GPU has.
> It looks like comment 65-67 describes graphical glitches occurring with
> DirectDrawRenderer=opengl - that sounds like it should be a separate bug
> report.
Yes. I think the problem is that wined3d can't read the color keyed surface
contents back. The game backs up the old content of the backbuffer before it
draws a sprite, and when it moves the sprite it draws the old contents back
rather than redrawing everything.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=5535
--- Comment #73 from Alex Bradbury <asb(a)asbradbury.org> 2011-06-27 10:08:26 CDT ---
(In reply to comment #72)
> I can reproduce the issue. The game tries to fill the entire video memory with
> surfaces. Each surface gets a DIB section, and GDI runs out of handles. In the
> old ddraw code it worked because it faked only 8 MB of video memory. Wined3d
> tries to make a reasonable guess based on your GPU, so usually you have up to
> two gigs of emulated vidmem.
>
> There are two workarounds: The first is to use the opengl renderer for
> directdraw, which doesn't need DIB sections for most of its surfaces. Or you
> could limit the video memory to a small size. See the useful registry keys wiki
> page for details on both settings.
Thanks for taking a look. What do you propose should happen to this bug? At the
very least I suggest changing the title to reflect the GDI running out of
handles issue that it seems to focus on (the current summary is far too vague).
It looks like comment 65-67 describes graphical glitches occurring with
DirectDrawRenderer=opengl - that sounds like it should be a separate bug
report.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=5535
--- Comment #72 from Stefan Dösinger <stefandoesinger(a)gmx.at> 2011-06-27 07:58:15 CDT ---
I can reproduce the issue. The game tries to fill the entire video memory with
surfaces. Each surface gets a DIB section, and GDI runs out of handles. In the
old ddraw code it worked because it faked only 8 MB of video memory. Wined3d
tries to make a reasonable guess based on your GPU, so usually you have up to
two gigs of emulated vidmem.
There are two workarounds: The first is to use the opengl renderer for
directdraw, which doesn't need DIB sections for most of its surfaces. Or you
could limit the video memory to a small size. See the useful registry keys wiki
page for details on both settings.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20680
Summary: winecfg: no Wave Out Devices under ALSA Drivers
(M-Audio Delta)
Product: Wine
Version: 1.1.32
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: marko.srebre(a)gmail.com
Winecfg shows no "Wave Out Devices" under "ALSA Drivers" section. I only get
"MIDI In Devices", "MIDI Out Device" and "Mixer Device" under the "ALSA
Drivers". Of course, sound doesn't work then in wine or in test.
Wine is compiled with alsa support, version is 1.1-32, but happens just the
same with older versions. I suspect the problem is specific to my M-Audio Delta
66 sound card. I use no sound servers or anything that may be restricting the
device. This card otherwise works flawlessly with every other application I am
using. Older version of wine would usually report something about missing
Master control, so I guess somethere there may be a problem, but not really
sure how to fix it.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=7640
Austin English <austinenglish(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #69 from Austin English <austinenglish(a)gmail.com> 2011-06-26 14:50:30 CDT ---
(In reply to comment #68)
> So then anyone can set FIXED?
Fixed.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.