http://bugs.winehq.org/show_bug.cgi?id=12179
Summary: MSN Messenger crash in Wine 0.9.58 while starting
Product: Wine
Version: 0.9.58.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jaimerave(a)gmail.com
Created an attachment (id=11576)
--> (http://bugs.winehq.org/attachment.cgi?id=11576)
Console output
After install it MSN Messenger will crash while loading in wine 0.9.58, it
starts if you set it to win2k.
--
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=16772
Summary: MSN Messenger 7.0: Scroll bar in chat window don't have
a limit
Product: Wine
Version: 1.1.12
Platform: PC
URL: http://www.microsoft.com/downloads/details.aspx?familyid
=CF49C56C-8B3E-4EAE-9904-9505F47BED45&displaylang=en
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jaimerave(a)gmail.com
If you're chatting in MSN and have write enough to make appear the scroll bar
you can scroll down the text without limit. The scroll is supposed to scroll
just until the end of the text.
--
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=12447
Summary: MSN Messenger 7.0 crash while loading the Contact list
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jaimerave(a)gmail.com
Created an attachment (id=11987)
--> (http://bugs.winehq.org/attachment.cgi?id=11987)
Console output
After Sign in and when it start to load the contact list msn messenger crash.
This happen in current git (08/04/2008). I attach the console output.
--
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=15305
Summary: MSN Messenger wont remember yor username and password
Product: Wine
Version: 1.1.3
Platform: PC
URL: http://www.oldapps.com/download.php?oldappsid=Install_MS
N_Messenger%207.5.exe
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msxml3
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jaimerave(a)gmail.com
Created an attachment (id=16135)
--> (http://bugs.winehq.org/attachment.cgi?id=16135)
Before install native MSXML3
MSN Messenger has the option to save your user name and password, but in Wine
it doesn't work at least that you install native MSXML3.
While typing you will see lots of this message:
XPath error : Undefined namespace prefix
xmlXPathEval: evaluation failed
--
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=14483
Summary: WinVerifyTrustEx doesn't return expected HRESULT for PE
images not digitally signed (TRUST_E_NOSIGNATURE)
Product: Wine
Version: CVS/GIT
Platform: PC
URL: http://www.filehippo.com/download_msn_messenger/751/
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wintrust
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
this is a follow-up bug of bug 12718
Enable tracing:
--- snip ---
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL\Trace]
"Level"=dword:00000099
--- snip ---
"msnmsgr.exe" PE image is *not* digitally signed.
Compare both:
--- snip windows trace ---
..
<3776, 3780>: Verifying calling process image is
signed...(a)passportclientlibrary.cpp_103
<3776, 3780>: Failed to WinVerifyTrustEx : C:\Program Files\MSN
Messenger\msnmsgr.exe. hr = 0x800b0100(a)util.cpp_802
<3776, 3780>: Failed to Verify the file signature : C:\Program Files\MSN
Messenger\msnmsgr.exe. hr = 0x800b0100(a)util.cpp_858
<3776, 3780>: Unable to verify caller is signed by MSFT cert 0x800b0100.
GetCertificate API will not function correctly.(a)passportclientlibrary.cpp_124
--- snip windows trace ---
vs.
--- snip wine trace ---
..
<8, 9>: Verifying calling process image is
signed...(a)passportclientlibrary.cpp_103
<8, 9>: Passed WinVerifyTrustEx : C:\Program Files\MSN Messenger\msnmsgr.exe.
@util.cpp_807
<8, 9>: Verify certificate against microsoft root : C:\Program Files\MSN
Messenger\msnmsgr.exe. @util.cpp_808
<8, 9>: Failed to Verify the file signature : C:\Program Files\MSN
Messenger\msnmsgr.exe. hr = 0x800b0100(a)util.cpp_858
<8, 9>: Unable to verify caller is signed by MSFT cert 0x800b0100.
GetCertificate API will not function correctly.(a)passportclientlibrary.cpp_124
--- snip wine trace ---
--- snip wine ---
0030:Ret imagehlp.ImageGetCertificateHeader() retval=00000000 ret=609fb7cc
..
0030:trace:wintrust:CryptSIPGetSignedDataMsg returning 0
0030:Ret wintrust.CryptSIPGetSignedDataMsg() retval=00000000 ret=607c4b2a
0030:trace:crypt:CryptSIPGetSignedDataMsg returning 0
0030:trace:wintrust:SoftpubLoadMessage returning 1 (800b0100)
0030:Ret wintrust.SoftpubLoadMessage() retval=00000001 ret=60a05942
0030:trace:wintrust:WINTRUST_DefaultVerify returning 00000001
0030:trace:wintrust:WinVerifyTrust returning 00000001
0030:Ret wintrust.WinVerifyTrustEx() retval=00000001 ret=003ad2e9
--- snip wine ---
Remember: S_FALSE is not a failure code at all.
The return code evaluation from messenger looks like an inlined FAILED() macro
((HRESULT)(Status)<0) which basically just tests if the result has the high bit
set.
They don't test for S_OK, hence it incorrectly reports "pass" in wine.
TRUST_E_NOSIGNATURE has to be propagated somewhere because that's what
WinVerifyTrustEx() should return in that case.
Reagrds
--
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=51438
Bug ID: 51438
Summary: Rust compiler crashes with "free(): double free
detected in tcache 2" message
Product: Wine
Version: 6.12
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mikrutrafal(a)protonmail.com
Distribution: ---
When I installed on clear prefix rustc with cargo -
https://static.rust-lang.org/dist/rust-1.53.0-x86_64-pc-windows-gnu.msi
```
wget https://static.rust-lang.org/dist/rust-1.53.0-x86_64-pc-windows-gnu.msi
msiexec /i rust-1.53.0-x86_64-pc-windows-gnu.msi
```
then after running commands
```
echo "fn main() { println!(\"Hello World!\");}" > roman.rs
rustc roman.rs
```
compiler crashes with this info(not sure if this is Wine or Rustc info)
```
free(): double free detected in tcache 2
```
I think that this issue is very important to fix, because Rust allows to run
tests via e.g. `cargo test` command which allows to execute tests inside
repository.
This probably will really help with testing Wine because tests are usually
small and it will be easy to track issue down.
There is a lot of rust repositories, but this two use directly windows API, so
testing them should give easy info about crashes etc.
https://github.com/microsoft/windows-samples-rshttps://github.com/microsoft/windows-rs
--
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=50804
Bug ID: 50804
Summary: LTSpice XVII will not start
Product: Wine
Version: 6.3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: will.nilges(a)gmail.com
Distribution: ---
Created attachment 69614
--> https://bugs.winehq.org/attachment.cgi?id=69614
.desktop startup errors
After installing LTSpice (which appears to work fine), the program will not
start, failing silently if you use the provided .desktop file (either of them),
and giving little helpful output otherwise.
I believe that LTSpice worked fine on some earlier version of Wine 6. 6.1 seems
to work.
A possibly related issue is that the installer complains at you with the
following message:
"You have User Account Control (UAC) enabled but did not 'Run As Administrator'
If you want to try to install in a directory you have full permissions, press
'YES' to continue anyway."
I'm running Fedora 33 with GNOME on Wayland. This happens on any of my Fedora
GNOME computers. I have tried no other operating system.
My current workaround is to downgrade to Wine 5.18.
--
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=51059
Bug ID: 51059
Summary: Incorrect semantics of FILE_OPEN_REPARSE_POINT on
Linux
Product: Wine-staging
Version: 6.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: jinoh.kang.kr(a)gmail.com
CC: erich.e.hoover(a)gmail.com, leslie_alistair(a)hotmail.com,
z.figura12(a)gmail.com
Distribution: ---
This bug affects the Cygwin installer (https://cygwin.com/setup-x86_64.exe);
specifically, it fails to verify SHA512 checksums of downloaded packages.
(Source at
https://cygwin.com/git/?p=cygwin-apps/setup.git;a=blob;f=package_source.cc,
in method packagesource::check_sha512)
Running the installer with WINEDEBUG=trace+file,trace+server reports:
CreateFileW ("XXXX.tar.xz") [1]
NtCreateFile ("XXXX.tar.xz", w/o FILE_OPEN_REPARSE_POINT) [1]
CreateFileW return [1]
NtQueryInformationFile FileBasicInformation [1]
(server)close_handle [1]
NtCreateFile ("XXXX.tar.xz", w/ FILE_OPEN_REPARSE_POINT) [2]
NtReadFile [2] -> STATUS_INVALID_HANDLE
The square brackets denote file handles. Handle reuse bug has been
ruled out.
This bug can be traced to an incorrect FILE_OPEN_REPARSE_POINT implementation
in Wine-staging, in
"ntdll-Junction_Points/0016-server-Implement-FILE_OPEN_REPARSE_POINT-option.patch":
> diff --git a/server/fd.c b/server/fd.c
> index 4f43f41fb31..a01d4c9c0f7 100644
> --- a/server/fd.c
> +++ b/server/fd.c
> @@ -107,6 +107,10 @@
> #include "winioctl.h"
> #include "ddk/wdm.h"
>
> +#if !defined(O_SYMLINK) && defined(O_PATH)
> +# define O_SYMLINK (O_NOFOLLOW | O_PATH)
> +#endif
On Linux, read/write/ioctl/... operations on an O_PATH descriptor will
fail with EBADF, which is then translated as STATUS_INVALID_HANDLE to the
application.
> +
> #if defined(HAVE_SYS_EPOLL_H) && defined(HAVE_EPOLL_CREATE)
> # include <sys/epoll.h>
> # define USE_EPOLL
> @@ -1958,6 +1962,11 @@ struct fd *open_fd( struct fd *root, const char *name, struct unicode_str nt_nam
> }
> else rw_mode = O_RDONLY;
>
> +#if defined(O_SYMLINK)
> + if ((options & FILE_OPEN_REPARSE_POINT) && !(flags & O_CREAT))
> + flags |= O_SYMLINK;
Another difference is that O_PATH semantics override
O_RDONLY/O_WRONLY/O_RDWR, even if the target file isn't _actually_ a
symbolic link.
To properly implement it on Linux we should:
1. open with O_PATH.
2. check if the file is really a symlink (via fstat?).
3. if not, reopen via /proc/self/fd/%u (now w/o O_NOFOLLOW|O_PATH).
Note that this isn't an issue on XNU (macOS), where O_SYMLINK has an
equivalent semantics to FILE_OPEN_REPARSE_POINT.
--
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.