http://bugs.winehq.org/show_bug.cgi?id=32050
Bug #: 32050
Summary: Running Dragon age 2 with High resolution textures
results in GL_OUT_OF_MEMORY errors
Product: Wine
Version: 1.5.15
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: xvachon(a)gmail.com
Classification: Unclassified
When Dragon Age 2 is run with the high resolution textures pack
(http://social.bioware.com/page/da2-patches), I get GL_OUT_OF_MEMORY errors in
about 30 seconds in game and it crashes. Some examples include :
err:d3d_surface:surface_allocate_surface >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY
(0x505) from glTexImage2D @ surface.c / 2747
err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501)
from glCompressedTexSubImage2DARB @ surface.c / 2364
err:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from
glDrawElementsBaseVertex @ drawprim.c / 48
err:d3d:buffer_create_buffer_object glBufferDataARB failed with error
GL_OUT_OF_MEMORY (0x505)
err:d3d:buffer_create_buffer_object Failed to create a vertex buffer object.
Continuing, but performance issues may occur
Running the game with the highest DirectX9 settings (Medium, Anti-aliasing 16x)
and High Res textures disabled works well on my system.
wine 1.5.15
Dragon age 2 1.04 with all DLC
Nvidia 550 Ti 2GB Ram
Arch Linux X64
--
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=25945
Summary: C_ASSERT doesn't fail if given non-constant expression
Product: Wine
Version: 1.1.22
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: alexander.scott.johns+winebug(a)googlemail.com
In commit wine-1.1.21-63-g5d31eb9 AJ changed the definition of C_ASSERT (in
include/winnt.h) to make it compatible with newer versions of GCC.
Roughly, the change was:
-#define C_ASSERT(e) extern char __C_ASSERT__[(e)?1:-1] __attribute__((unused))
+#define C_ASSERT(e) extern void __C_ASSERT__(int [(e)?1:-1])
Unfortunately, in GCC 4.4.3, the new definition of C_ASSERT doesn't fail when
given a non-constant expression. E.g.:
C_ASSERT(rand() == -1); /* ignored */
I think this is because GCC (as per C99) is treating the parameter of
__C_ASSERT__ as a VLA (variable length array), and so its type is equivalent to
int[*].
--
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.
https://bugs.winehq.org/show_bug.cgi?id=38271
Bug ID: 38271
Summary: The Docear4Word plugin for MS Word does not work at
all
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: whynot(a)nurfuerspam.de
Distribution: ---
Created attachment 51098
--> https://bugs.winehq.org/attachment.cgi?id=51098
Debug output trying to install/launch docear4word with Word
Docear4Word is a FOSS plugin for MS Word, which allows creating citations and
bibliography in MS Word based on a BibTeX database.
Information about this plugin can be found here:
http://www.docear.org/software/add-ons/docear4word/overview/
This is the download link:
http://docear.org/download/docear4word_setup.exe
The plugin's source code is also available:
http://docear.org/download/docear4word_source.zip
I tried installing this in both Word 2007 and Word 2010. In both cases, the
install of the plugin appears to finish without any errors (in the GUI).
In Word 2007, the progress is a little bit better, since the plugin at least
shows up in the preferences (Word Options => Add-Ins => Inactive Application
Add-ins lists "Docear4Word"). Obviously, since it is inactive, something went
wrong. Also by following "Manage => Add-Ins => COM-Add-Ins" one gets to a modal
pop-up window, which lists all COM Add-Ins. "Docear4Word" appears, but is
unchecked. If one checks it and goes to the same window again (COM Add-Ins), it
will say "Load Behavior: Not loaded. A runtime error occurred during the
loading of the COM Add-in."
If one turns wine debug output on, the are some specific errors in the command
line (see attachment, 1st part), perhaps most importantly
"fixme:ole:CoCreateInstance no instance created for interface
{b65ad801-abaf-11d0-bb8b-00a0c90f2744} of class
{34f82078-360b-4682-8275-0d9b0b641cbd}, hres is 0x800704e5"
In Word 2010, the add-in does not even show up in Word whatsoever. Trying to
manually launch the docear4word.exe installer from the Add-ins Window by using
"Add", there is also some debug output in the console (see attachment, 2nd
part).
The Add-in uses .NET, so an obvious question is how to handle the .NET. I tried
various approaches using several .NET versions and service packs via
winetricks, and I believe also mono. Nothing worked. I do not remember the
outcome of every single variant, but could try specific suggestions.
This add-in is really important, since many in the science community are using
Linux, but have to work with MS Word via wine for several reasons. Most in the
science community use such plug-ins for reference management. Docear4Word is
perhaps the most promising, powerful, and viable one, since the Docear4Word
project strictly follows an FOSS approach. Getting this to work would thus be a
huge progress.
--
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=33065
Bug #: 33065
Summary: Make it possible to build a winetest executable with a
single test
Product: Wine-Testbot
Version: unspecified
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: fgouget(a)codeweavers.com
Classification: Unclassified
Currently WineTestBot runs individual tests through TestLauncher (see
testbot/src/TestLauncher). TestLauncher is responsible for checking for
potential issues like missing dlls that could cause the test to hang on an
error dialog. However that means duplicating a lot of WineTest's code and also
that TestLauncher tends to be out of date (see bug 31609 for instance).
Building the regular winetest.exe (with all the tests) and just running one
test would result in a lot of wasted disk space and bandwidth.
So the idea would be to make it possible to build winetest.exe and to only
include the one test we want to run in the resources.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=47997
Bug ID: 47997
Summary: Allow setting $WINEDEBUG
Product: Wine-Testbot
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
To figure out why a test is failing in a TestBot Wine VM it would sometimes be
useful to be able to set $WINEDEBUG.
The trouble with $WINEDEBUG is that it can result in very large logs (e.g. if
set to +all or _relay). But then the tests can already generate large files by
looping on a printf() so that's not really a new issue, it's just less likely
to happen accidentally.
The way to deal with that would be to limit the size of the log and reports
that the TestBot retrieves from the VMs.
Notes:
* The TestBot already collects the whichever traces Wine puts out which would
typically be the FIXME()s and ERR()s. They are at the end of the "full task
log".
* So a workaround is to patch Wine to convert the relevant traces to FIXME()s.
That's not very practical if one does not initially know which ones are going
to be needed which is why being able to set $WINEDEBUG would be better.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=47900
Bug ID: 47900
Summary: Enable caching of screenshots and log files
Product: Wine-Testbot
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
web/Screenshot.pl and web/GetFile.pl systematically disable caching of the
files they return by setting their Last-Modified field to the current time.
For Screenshot.pl this may have been to deal with live screenshots that were
updated regularly. But even so this should probably be done through the Expires
field instead. Anyway we don't have live snapshots anymore and when they come
back it will (most likely) be in the form of a timestamped filename so that
once written a file would not change.
The only case where a file may change is when a job is canceled and restarted.
That does not seem to warrant disabling caching altogether.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=47901
Bug ID: 47901
Summary: Stream the files in Screenshot.pl and GetFile.pl
Product: Wine-Testbot
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
Screenshot.pl and GetFile.pl load their files entirely in memory before
returning them. That's wasteful.
Also GetFiles.pl loads it in a $ImageBytes variable despite returning patches
and executables.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=44684
Bug ID: 44684
Summary: Shaders fail to compile in Roblox Studio (white
window)
Product: Wine
Version: 3.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: and3md(a)gmail.com
Distribution: ---
Created attachment 60693
--> https://bugs.winehq.org/attachment.cgi?id=60693
Roblox Studio run log
The application displays splash screen correctly. Next, the main window is
showed which is "empty" (the window is white). The cursor changes its shape in
some places so probably it's just a display case. Wine returns a lot of errors:
007d: err: d3dcompiler: compile_shader HLSL shader parsing failed.
007d: fixme: hlsl_parser: declare_vars Complex initializers are not supported
yet.
Hardware: Geforce GTX 1060 (proprietary linux driver).
--
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=19329
Summary: Program installs but client fails to connect to server
Product: Wine
Version: 1.1.25
Platform: PC
URL: http://www.livezilla.net/
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: junk(a)mandd.com
Using Wine 1.1.25 and a clean ~/.wine, I had to install dotnet20 and ie6 (I
used winetricks) before the installer would complete. After that the Livezilla
client will run. But when I try to connect to a Livezilla server, an error
window pops up stating:
--------------------------------------------------------------------
The underlying connection was closed: The connection was closed unexpectedly.
Further information:
The underlying connection was closed: The connection was closed unexpectedly.
--------------------------------------------------------------------
--
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=34865
Bug #: 34865
Summary: Can't execute mingw toolchain provided by Rtools
Product: Wine
Version: 1.7.4
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mail(a)kirill-mueller.de
Classification: Unclassified
I can't execute "R CMD INSTALL" on an installation of R + Rtools in Wine
(latest version from PPA "ppa:ubuntu-wine/ppa"). A reproducible script and
console output can be found here: https://gist.github.com/krlmlr/7333242 . The
script will set and write to $WINEPREFIX and download to $DOWNLOAD_DIR.
Unfortunately, the logs do not show enough detail. After the line `about to run
R CMD SHLIB -o kimisc.dll rcpp_hello_world.cpp RcppExports.cpp --debug`, a call
to `gcc` is made. (I have added the output of the same call on my Linux system
to the Gist.) To me, it seems that the calling process is not notified when the
child process has completed, and it stops after a timeout. My hope is that this
has been seen before and that there's an easy fix. I'm really new to Wine.
--
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.