https://bugs.winehq.org/show_bug.cgi?id=38886
Bug ID: 38886
Summary: AArch64 platforms: ABI Problems wrt varargs (needs
arm64 specific __builtin_ms_va_list)
Product: Wine
Version: 1.7.46
Hardware: aarch64
URL: http://go.microsoft.com/fwlink/p/?LinkId=536682
OS: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: nerv(a)dawncrow.de
CC: focht(a)gmx.net, nerv(a)dawncrow.de
Distribution: ---
Hi,
running e.g. makecat.exe or midl.exe gives backtraces which suggest varargs
problems.
relevant part:
(stripped) Backtrace:
=>0 0x0000007f84d4aa04 raise_segv_exception(rec=0x7f83e8fa18,
context=0x7f83e8f908) in ntdll (0x0000007f83e8fab0)
1 0x0000007f83d65864 pf_printf_w+0x8cb(pf_puts=0x7f83d61b18,
puts_ctx=0x7f83e8fc70, fmt=<is not available>, locale=<is not available>,
positional_params=0, invoke_invalid_param_handler=0x740020,
pf_args=0x78003000200068, args_ctx=0x2d0020003a0000, valist=0x7f83e8fcb0) in
msvcrt (0x0000007f83e8fab0)
2 0x0000007f83d65864 pf_printf_w+0x8cb(pf_puts=0x7f83d67ec0,
puts_ctx=0x7f83e8fc70, fmt=<is not available>, locale=<is not available>,
positional_params=0, invoke_invalid_param_handler=0, pf_args=0x7f83d617d8,
args_ctx=0x0(nil), valist=0x7f83e8fcc8) in msvcrt (0x0000007f83e8fac0)
3 0x0000007f83d65864 pf_printf_w+0x8cb(pf_puts=0x7f836822c0,
puts_ctx=0x0(nil), fmt=<is not available>, locale=<is not available>,
positional_params=0x40020000, invoke_invalid_param_handler=0x7f,
pf_args=0x140020000, args_ctx=0x140020000, valist=0x7f84280910) in msvcrt
(0x0000007f83e8fc50)
4 0x0000007f83d67ec0 MSVCRT_vsnwprintf+0x47(str=<is not available>, len=<is
not available>, format=<is not available>, valist={__stack=0x7f836819f0,
__gr_top=0x140010170, __vr_top=0x7f8428071c, __gr_offs=0x83681a28,
__vr_offs=0x7f}) in msvcrt (0x0000007f83e8fc80)
5 0x0000000140012328 in makecat (+0x12327) (0x0000007f83e8fcb0)
6 0x00000001400123b0 in makecat (+0x123af) (0x0000007f83e8fcb0)
uuidgen.exe -i
this generates a different path which involves MSVCRT_vsnprintf, pf_printf_a
and pf_handle_string_a
--
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=43287
Bug ID: 43287
Summary: Farming Simualtor 17
Product: Wine
Version: 2.11
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3dx11
Assignee: wine-bugs(a)winehq.org
Reporter: sascha.spaces(a)yandex.ru
Distribution: ---
Created attachment 58629
--> https://bugs.winehq.org/attachment.cgi?id=58629
Backtrace
Farming Simulator 17 does not start. The log is here.
I'm from Russia and use google translator. There may be errors in the text.
closed the game for abit but when i got back and tried playing it said could
not init 3d system shader model is required and this is confusing me since a
just played it and i check if anything needed a driver update.
--
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=50779
Bug ID: 50779
Summary: winegstreamer is leaking something
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winegstreamer
Assignee: wine-bugs(a)winehq.org
Reporter: galtgendo(a)o2.pl
Distribution: ---
A rough summary of the problem and things said on chat.
Awhile ago a thing, that had been working reasonably well for quite a few years
(with exception of a short period when code changes made the music stop
looping), has began to randomly freeze to a point that you'd needed to wait for
wm's kill dialog to appear after trying to close the main window.
The messages in the console were saying something about being unable to create
thread due to running out of resources. The freezes usually took a quite a bit
of time, but didn't seem to have any obvious trigger.
As far as free memory went, the situation was still fine at such time, but zf
suggested it was an address space problem. Forcibly setting the executable to
LARGE_ADDRESS_AWARE gave it more running time, but eventually seem to have
resulted in a whole system freeze.
As such, I was once put into realm of wild ass guesses and even crazier
attempted solutions.
So, I took a gamble and removed gst_object_ref calls from
mpeg_audio_parser_init_gst and wave_parser_init_gst first.
This didn't seem to have any effect.
Then I've removed the last gst_object_ref - one in pad_added_cb.
This resulted in a flood of 'gst_object_unref: assertion '((GObject *)
object)->ref_count > 0' failed', yet after running for quite awhile the freeze
is yet to happen.
Now, this is far from conclusive, as we're trying to literally prove a negative
here, but it would align well with the fact that free memory used at the time
of freeze isn't all that significant.
I'm not sure when the problem began. I think it was somewhere between 5.22 and
6.1 (though only the upper bound being definite).
--
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=26715
Summary: Win1.0 executable triggers Dosbox
Product: Wine
Version: 1.3.17
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: spammis(a)spam.la
$ wine paint
This seems to be a very old (pre-3.0) Windows executable. Expect crashes,
especially if this is a real-mode binary !
DOSBox version 0.74
Copyright 2002-2010 DOSBox Team, published under GNU GPL.
---
CONFIG:Loading primary settings from config file
/home/user/.wine/dosdevices/c:/users/user/Temp/cfg1bc1.tmp
MIXER:Got different values from SDL: freq 44100, blocksize 512
ALSA:Can't subscribe to MIDI port (65:0) nor (17:0)
MIDI:Opened device:none
$
The executable (paint/PAINT.EXE) is the Windows 1.0 version of Paint. Wine
properly recognises it as a "very old" Windows executable, but after doing
that, Wine thinks that it is a DOS executable and tries to launch Dosbox.
Dosbox gives the usual message: "This program requires Microsoft Windows." The
lines about the old executable come from Wine while the rest of the lines come
from Dosbox.
--
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=43996
Bug ID: 43996
Summary: 2GIS: error after exiting
Product: Wine
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: spck(a)yandex.ru
Distribution: ---
Created attachment 59653
--> https://bugs.winehq.org/attachment.cgi?id=59653
just backtrace automatically formed by Wine
Wine crashes when I successfully close 2GIS application
--
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=51227
Bug ID: 51227
Summary: urlmon:url breaks the wininet:http test on Windows 10
1709+
Product: Wine
Version: 6.8
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: wininet
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
WineTest shows that wininet:http has the following set of failures on Windows
10 1709+:
https://test.winehq.org/data/patterns.html#wininet:http
http.c:6732: Test failed: expected secure flag to be set
http.c:6742: Test failed: InternetQueryOption failed: 12016
http.c:6748: Test failed: InternetQueryOption failed: 12016
http.c:6771: Test failed: InternetQueryOption failed: 12016
http.c:6776: Test failed: InternetQueryOption failed: 12016
http.c:6779: Test failed: expected same string
However, when run on its own, the test always succeeds!
Further testing shows that to reproduce the failure one must first run
urlmon:url. More specifically:
urlmon_test.exe url
wininet_test.exe http -> fails
wininet_test.exe http -> succeeds
So urlmon:url breaks the wininet:http that follows, but wininet:http fixes
whatever urlmon:url broke so that the next wininet:http run succeeds.
So it seems like there are two bugs:
* urlmon:url does not correctly clean up one of the changes it makes.
* And wininet:http performs a similar change but instead of restoring the
configuration as it was when the test started, it restores the default Windows
configuration.
--
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=45542
Bug ID: 45542
Summary: regression: WeGame hangs after login.
Product: Wine
Version: 3.13
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: advapi32
Assignee: wine-bugs(a)winehq.org
Reporter: jactry92(a)gmail.com
Distribution: ---
Created attachment 61948
--> https://bugs.winehq.org/attachment.cgi?id=61948
0001-Revert-server-Assign-a-default-label-to-all-tokens.txt
WeGame is a game platform by Tencent.
Steps to reproduce:
1. $ winetricks -q mfc42 cjkfonts
2. $ wine WeGameMiniLoader.3.6.1.5080.gw.exe
3. $ cd .wine/drive_c/Program\ Files/WeGame
4. $ WINEDLLOVERRIDES="msvcr100=n" wine tgp_daemon.exe
5. Due to bug 45540 , we can't login by an account number and password. But we
can login it by scanning its QR code. Clicking the Wechat icon and scaning the
QR code on WeChat mobile for login.
Expected: We can login and enter WeGame's game store interface.
Actually: Login successfully but it will hang.
I found that it work well on Wine-2.8 and I did a regression tests for it found
that this commit broke it:
commit a78d419420a43e1f428ac155082b87143117e381
Author: Michael Müller <michael(a)fds-team.de>
Date: Fri Jun 16 20:41:36 2017 +0200
server: Assign a default label to all tokens.
0001-Revert-server-Assign-a-default-label-to-all-tokens.txt is a patch for
reverting this commit on current Wine-3.13. And with this reverting WeGame
doesn't hang again.
--
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=50351
Bug ID: 50351
Summary: Slow text rendering in dofus linked to
fnIMLangFontLink2_GetCharCodePages calling
WideCharToMultiByte with CP_UNICODE
Product: Wine
Version: 6.0-rc2
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: mlang
Assignee: wine-bugs(a)winehq.org
Reporter: eijebong+wine(a)bananium.fr
Distribution: ---
Created attachment 68941
--> https://bugs.winehq.org/attachment.cgi?id=68941
Patch that fixes the text rendering slowness (probably wrong)
Dofus is very slow to render text and changing communication channels can hang
the game for a few seconds.
Profiling shows that it's spending lots of time opening files.
Tracing shows it's trying to open c_1200.nls a *lot*. That file doesn't exist.
Discussion on IRC:
```
22:45:27 nsivov> so that comes from mlang
22:45:47 gofman> mind umbstowcs and friends... what if it really ends up
searchign / opening locale file each time due to some reason (which can be
fixed)
22:46:37 gofman> or maybe it doesn't find some locale and tries again on each
character
22:48:07 zf> no such code page on Windows either
22:48:33 zf> we should probably cache failed attempts there
22:48:45 nsivov> in mlang it goes 1 char at a time * mlang_data size
22:49:30 gofman> cache missing is strange, but maybe some cached list of which
locale exist is possible
[...]
22:55:15 julliard> that's an mlang bug, CP_UNICODE is not a real codepage
22:57:01 nsivov> yes, for that particular loop it should be excluded
[...]
23:38:04 zf> just judging from the diagnosis above, it seems like
fnIMLangFontLink2_GetCharCodePages() is using CP_UNICODE in
WideCharToMultiByte() when it shouldn't
```
The attached diff fixes the slowness but is probably not correct and I
certainly don't understand enough about the cause to either write a meaningful
commit message or a test.
--
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=32643
Bug #: 32643
Summary: getsockopt() does not indicate WSAEFAULT when setting
optlen too small
Product: Wine
Version: 1.5.20
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: winsock
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: alexander255(a)lavabit.com
Classification: Unclassified
Using the attached WSA code will cause an error on Windows but NOT on WINE.
If you change "optlen" value to at least 4, the example the code will run
smoothly on both platforms.
--
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.