https://bugs.winehq.org/show_bug.cgi?id=49763
Bug ID: 49763
Summary: ALOTInstaller crashes
Product: Wine
Version: 5.16
Hardware: x86
OS: Linux
Status: NEW
Keywords: dotnet, download
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: xerox.xerox2000x(a)gmail.com
Distribution: Debian
Created attachment 68064
--> https://bugs.winehq.org/attachment.cgi?id=68064
crash log
A user reported this as rated "garbage" in appdb, so i gave it a try
The crash log shows a call to RtlConvertToAutoInheritSecurityObject, which is
strange as the FIXME from that stub is not printed in console; is that normal?
One issue is at least that RtlConvertToAutoInheritSecurityObject is wrong
declared, see https://bugs.winehq.org/show_bug.cgi?id=33279#c1
but then committed patch declares it as BOOL:
https://bugs.winehq.org/show_bug.cgi?id=33279#c3
I`ll send a patch for that one.
But that is not the cause of the crash, even if i remove
RtlConvertToAutoInheritSecurityObject from ntdll.spec it shows up in the crash
log (???)
So anyone knows what`going on? Note: I don`t know exactly what .net it needs, I
tried dotnet40 and dotnet48, same crash happens
Unhandled exception: 0xe0434352 in 64-bit code (0x000000007b01129e).
.
.
Backtrace:
=>0 0x000000007b01129e format_exception_msg+0x32e(ptr=<is not available>,
buffer=<is not available>, size=<is not available>)
[Z:\home\louis\sda2\wine64-build\dlls\kernelbase\..\..\..\wine\dlls\kernelbase\debug.c:315]
in kernelbase (0x0000000000512d60)
1 0x000006447fd60412 EntryPoint+0x6440003ef15() in msvcr100_clr0400
(0x0000000000512d60)
2 0x000000007bc521e1 RtlConvertToAutoInheritSecurityObject+0x200(pdesc=<is
not available>, cdesc=<is not available>, ndesc=<is not available>, objtype=<is
not available>)
[Z:\home\louis\sda2\wine64-build\dlls\ntdll\..\..\..\wine\dlls\ntdll\sec.c:1721]
in ntdll (0x0000000000512d60)
3 0x000006447fd5f5a7 EntryPoint+0x6440003e0aa() in msvcr100_clr0400
(0x0000000000516319)
--
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=22327
Summary: download
Product: Wine
Version: 1.1.42
Platform: x86
URL: http://sourceforge.net/projects/phpgedview/files/1%20P
hpGedView/PhpGedView%20v4.2.3/PGV-Demo-4.2.3.zip/downl
oad
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: leighmanthegreat(a)hotmail.com
Cannot install PGV demo for Windows using a clean wineprefix.
After installing dotnet20sp2 Mono2.4 with winetricks I get the following
output:
err:module:import_dll Library php5ts.dll (which is needed by
L"Z:\\home\\jack\\PGV test\\democd\\httpd\\php\\php5apache2_2.dll") not found
(OS 10048)Address already in use: make_sock: could not bind to address
127.0.0.1:6880
no listening sockets available, shutting down
Unable to open logs
System.OverflowException: Number overflow.
at System.Drawing.SizeF.ToSize () [0x00000]
at System.Windows.Forms.MessageBox+MessageBoxForm.InitFormsSize () [0x00000]
at System.Windows.Forms.MessageBox+MessageBoxForm.RunDialog () [0x00000]
at (wrapper remoting-invoke-with-check)
System.Windows.Forms.MessageBox/MessageBoxForm:RunDialog ()
at System.Windows.Forms.MessageBox.Show (System.String text) [0x00000]
at PGVDemo.Form1.button1_Click (System.Object sender, System.EventArgs e)
[0x00000]
at System.Windows.Forms.Control.OnClick (System.EventArgs e) [0x00000]
at System.Windows.Forms.Button.OnClick (System.EventArgs e) [0x00000]
at System.Windows.Forms.ButtonBase.OnMouseUp
(System.Windows.Forms.MouseEventArgs mevent) [0x00000]
at System.Windows.Forms.Button.OnMouseUp (System.Windows.Forms.MouseEventArgs
mevent) [0x00000]
at System.Windows.Forms.Control.WmLButtonUp (System.Windows.Forms.Message& m)
[0x00000]
at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m)
[0x00000]
at System.Windows.Forms.ButtonBase.WndProc (System.Windows.Forms.Message& m)
[0x00000]
at System.Windows.Forms.Button.WndProc (System.Windows.Forms.Message& m)
[0x00000]
at System.Windows.Forms.Control+ControlWindowTarget.OnMessage
(System.Windows.Forms.Message& m) [0x00000]
at System.Windows.Forms.Control+ControlNativeWindow.WndProc
(System.Windows.Forms.Message& m) [0x00000]
at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr
wParam, IntPtr lParam) [0x00000]
--
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=50093
Bug ID: 50093
Summary: Lara Croft and the guardian of light have very low
performance without neckloop even at lowest resolution
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: andy86(a)fastwebnet.it
Distribution: ---
Created attachment 68566
--> https://bugs.winehq.org/attachment.cgi?id=68566
plain wine console output at 640x480 with lowest settings and
+fps,+tid,+timestamp
Lara Croft and the guardian of light runs well at 60 fps (and at 100 and more
fps if vsync is disabled) on the menu, but during the game it has a performance
drop of about 14 fps even at the lowest resolution and with the settings as low
as possible.
CPU usage is around 20-35% for the game for a maximium total of approx 60%
consider steam and wineserver, and 5-10% max GPU load measured at 640x480
resolution and lowest possible graphics settings and approx 300mb of RAM so
it's do not appear as an hardware bottleneck.
I tried some old versions (about 3.x) of wine to exclude other regressions
(like bug 46942) and the performance on all tested versions are identical.
I also tried wine-staging with pba patches and all mentioned wine version with
unsupported dxvk and dgvoodo2 and performance are identical also on it.
So it seems that the problem is not in d3d* and something others goes wrong in
Wine, but I am not able to define exactly what.
--
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=43343
Bug ID: 43343
Summary: Palette corruption or wrong/corrupted colours
Product: Wine
Version: 2.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: alehiphopdj2(a)hotmail.com
Distribution: ---
Created attachment 58684
--> https://bugs.winehq.org/attachment.cgi?id=58684
ZIP file with 3 screenshots of Frank Herbert's Dune showing colours wrong
Playing Frank Herbert's Dune (2001) on Wine 2.12 on Linux (Ubuntu) from a fresh
and successful installation, colours are corrupted on:
- cutscenes (realtime rendering, not videos)
- gameplay
- title screen
I attach a zip file with these 3 screenshots.
These are the errors i get on the console:
fixme:win:EnumDisplayDevicesW ((null),0,0x33f0d4,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33ea04,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33f404,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x33f3b4,0x00000000), stub!
fixme:ddraw:wined3d_colour_from_ddraw_colour Unhandled pixel format.
fixme:ddraw:wined3d_colour_from_ddraw_colour Unhandled pixel format.
fixme:ddraw:wined3d_colour_from_ddraw_colour Unhandled pixel format.
fixme:ddraw:wined3d_colour_from_ddraw_colour Unhandled pixel format.
fixme:ddraw:wined3d_colour_from_ddraw_colour Unhandled pixel format.
fixme:ddraw:wined3d_colour_from_ddraw_colour Unhandled pixel format.
fixme:ddraw:wined3d_colour_from_ddraw_colour Unhandled pixel format.
fixme:ddraw:wined3d_colour_from_ddraw_colour Unhandled pixel format.
fixme:ddraw:wined3d_colour_from_ddraw_colour Unhandled pixel format.
fixme:ddraw:ddraw_surface7_Flip Ignoring flags 0x1.
err:d3d:wined3d_format_get_float_color_key Unhandled color key to float
conversion for format WINED3DFMT_R8G8_SNORM_L8X8_UNORM.
err:d3d:wined3d_format_get_float_color_key Unhandled color key to float
conversion for format WINED3DFMT_R8G8_SNORM_L8X8_UNORM.
err:d3d:wined3d_format_get_float_color_key Unhandled color key to float
conversion for format WINED3DFMT_R8G8_SNORM_L8X8_UNORM.
err:d3d:wined3d_format_get_float_color_key Unhandled color key to float
conversion for format WINED3DFMT_R8G8_SNORM_L8X8_UNORM.
...
(this last error repeating all time until the end)
Looks like colours are corrupted because this error...
--
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=41316
Bug ID: 41316
Summary: aplikasi ada masalah saat dibuka
Product: WineHQ Apps Database
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: appdb-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: santosoa141(a)yahoo.com
Distribution: Ubuntu
aplikasi kolotibablo ada masalah saat di buka
--
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=32725
Bug #: 32725
Summary: VC runtime functions crash when called from reloaded
library in a thread
Product: Wine
Version: 1.3.24
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msvcrt
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: most(a)museresearch.com
Classification: Unclassified
Created attachment 43181
--> http://bugs.winehq.org/attachment.cgi?id=43181
msvcrt-dll-problem.zip
Assume WHAT.DLL is a windows DLL with static MSVCRT linkage. If WHAT.DLL is
unloaded and reloaded, it's C runtime functions like std::cout can crash when
called from a thread.
According to Piotr Caban (piotr dot caban at gmail dot com) "The crash is
caused by incomplete FlsFree implementation. There's a comment in it's code
that says what needs to be added:
/* FIXME: add equivalent of ThreadZeroTlsCell here */"
The crash is repeatable with the attached example winelib program (captain.exe)
and windows DLL (what.dll). Code for the compiled what.dll is included. An
included README file describes the contents. 'make test' demonstrates the
problem.
--
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=50293
Bug ID: 50293
Summary: native dxdiag complains about missing dxapi.sys (et
al)
Product: Wine
Version: 6.0-rc1
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
Distribution: ---
To reproduce:
winetricks -q dxdiag
wine dxdiag
Click no to driver check
Choose 'DirectX Files' tab (2nd)
The notes field complains:
Several files (dxapi.sys, d3dpmesh.dll, dpmodemx.dll, etc.) are missing!
You'll see several missing files:
dxapi.sys
d3dpmesh.dll
dpmodemx.dll
dpvvox.dll
dpvacm.dll
dpnhupnp.dll
dimap.dll
diactfrm.dll
gcdef.dll
dsound3d.dll
dsdmoprp.dll
dx7vb.dll
encapi.dll
qdv.dll
qedwipes.dll
I have stubs for these, after which dxdiag reports success (for that test,
there are still other failures..). The last round of sent patches, for
reference:
https://source.winehq.org/patches/data/196982
However I suspect they should probably wait until after code freeze. In any
event, the bug needed to be reported.
--
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=33660
Bug #: 33660
Summary: CS:GO - Call votes respond
Product: Wine
Version: 1.5.30
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: pepe(a)bloodkings.eu
Classification: Unclassified
Once a player can call vote, and only works the first choice (F1, 1).
--
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=31787
Bug #: 31787
Summary: Run the tests in Wine
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
The Wine TestBot runs the conformance tests on Windows VMs before they are
committed to Wine. This greatly helped improve the quality of our conformance
tests.
The next step is making sure that the conformance tests work reliably in Wine
too, and that Wine patches don't break them. The hope is that this will help us
improve the state of the WineTest results:
http://test.winehq.org/data/
Doing so will be much more processor intensive than the current process:
* Currently only the conformance test patches are tested whereas we would need
to test almost every single patch (we could ignore some documentation patches
for instance).
* Currently we only have to generate a binary for the one conformance test
that's impacted. That's quick. Testing all Wine patches will require
recompiling Wine every time which takes more time, even with ccache.
* A Wine patch can have wide-ranging effects. For instance a patch to ntdll
could impact pretty much any conformance test. That means rerunning all of them
for every patch... unless we find reliable ways of pruning them (patches to
conformance tests would be an obvious optimization).
* Like for Windows we will need to test various configurations: different
locales; 32, 64 and 32+64 bit Wine builds; different sound backends; possibly
different Linux distributions; if possible FreeBSD and Solaris too (I'm leaving
Mac OS X for another bug). In some cases the same binaries can be used for
multiple tests (e.g. if only the locale changes) but in other cases not.
* Also for the current Wine TestBot an unreliable test only impacts people
modifying that test. But the above point means an unreliable test would impact
most Wine patches, leading to lots of patches being rejected. So this means
unreliable tests become a big issue and need to be handled in some way: fixed
or blacklisted or still run but not considered cause for rejection (so one can
notice when they get fixed).
Then there is the question of whether this should be done by modifying the Wine
TestBot or by using the BuildBot framework:
http://trac.buildbot.net/wiki/AboutBuildbot
Dan Kegel produced a proof of concept system based on BuildBot:
http://wiki.winehq.org/BuildBot
An issue is that without significant integration work, having both a
WineTestBot and BuildBot system would be annoying:
* The Wine TestBot currently has its own user database and BuildBot would add
another one. So it would be one more login to manage for developers unless we
manage to integrate either with another user database (e.g. through LDAP).
* Developers would have to submit patches to both sites and check the results
on both.
* Integration with the Wine Patches site (http://source.winehq.org/patches/)
would need to work with both systems.
--
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.