wine-bugs December 2009

wine-bugs@winehq.org

1 participants
6346 discussions

[Bug 20745] New: WinZip 12.1 installer subprocess crashes during installation
by wine-bugs＠winehq.org 04 Dec '09

04 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20745 Summary: WinZip 12.1 installer subprocess crashes during installation Product: Wine Version: 1.1.33 Platform: PC URL: http://download.winzip.com/wzd/winzip121.exe OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: ole32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: arethusa26(a)gmail.com Created an attachment (id=24813) --> (http://bugs.winehq.org/attachment.cgi?id=24813) WinZip 12.1 installer standard error With wine-1.1.33-150-g4990ca0, during the WinZip 12.1 installation process, the installer invokes the installed winzip32.exe at a certain point in the installation, resulting in: Backtrace: =>0 0x00a7d046 (0x0033fd04) 1 0x7e6fcbca apartment_release+0x15a(apt=0x157818) [/home/andrew/wine-git/dlls/ole32/compobj.c:597] in ole32 (0x0033fd44) 2 0x7e6fd9e2 CoUninitialize+0x152() [/home/andrew/wine-git/dlls/ole32/compobj.c:1385] in ole32 (0x0033fd74) 3 0x7e7254b7 OleUninitialize+0x67() [/home/andrew/wine-git/dlls/ole32/ole2.c:263] in ole32 (0x0033fd94) 4 0x004523e6 in winzip32 (+0x523e6) (0x0033fd9c) ... The standard error output is attached. -- 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.

1 6

[Bug 20739] New: winecfg emits a warning called an error
by wine-bugs＠winehq.org 04 Dec '09

04 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20739 Summary: winecfg emits a warning called an error Product: Wine Version: 1.1.33 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: herrold(a)owlriver.com wine-1.1.33-0.el5.mh (Mike Harris packaging for CentOS 5) see: http://wiki.centos.org/AdditionalResources/Repositories for a pointer Ran winecfg, with the 800x600 desktop option set and got: err:x11drv:X11DRV_CreateBitmap Trying to make bitmap with planes=1, bpp=32 This seems to be an uncaught warning, and not an error -- if there a 'try' option to permit detection and 'swallowing' it? -- Russ herrold -- 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.

1 4

[Bug 20715] New: ACDSee 3.0 (old version) hanging on exit
by wine-bugs＠winehq.org 04 Dec '09

04 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20715 Summary: ACDSee 3.0 (old version) hanging on exit Product: Wine Version: 1.1.33 Platform: PC URL: http://www.oldversion.com/download_ACDSee_3.0.html OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: lahmbi5675(a)gmx.de Wine version is 1.1.33, mode is win98. This is a really old version of ACDSee, download link above, not to be confused with current ACDSee 3.0 Pro, which is a completely different application. I'm just starting ACDSee and exiting without any further action, getting this in the console output: err:ntdll:RtlpWaitForCriticalSection section 0x7bc9f660 "exception.c: vectored_handlers_section" wait timed out in thread 001e, blocked by 0009, retrying (60 sec) I then have to do "winserver -k", if I want to properly start ACDSee again. -- 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.

1 4

[Bug 20692] New: Probable benign window title leak
by wine-bugs＠winehq.org 04 Dec '09

04 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20692 Summary: Probable benign window title leak Product: Wine Version: 1.1.32 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com This is another case of 'a leak so small it doesn't matter'. I think it only happens once per window, and only when the window doesn't get an NCDESTROY message before exiting. I'm filing it and marking it WONTFIX so the valgrind suppression I create can point to a bug report for explanation. http://kegel.com/wine/valgrind/logs/2009-11-11-07.36/vg-user32_msg.txt says user32_test.exe.so msg.c leaks like this: 22 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by DEFWND_SetTextA (defwnd.c:98) by DefWindowProcA (defwnd.c:834) by MsgCheckProc (msg.c:7274) by MsgCheckProcA (msg.c:7283) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_call_window (winproc.c:2223) by call_window_proc (message.c:1635) by send_message (message.c:2482) by SendMessageA (message.c:2627) by WIN_CreateWindowEx (win.c:1342) by CreateWindowExA (win.c:1541) And http://kegel.com/wine/chromium/valgrind-logs/base_unittests/MessageLoopTest… says that base_unittests.exe --gtest_filter=MessageLoopTest.RecursiveDenial2 and a couple others leak as follows: 8 bytes in 4 blocks are definitely lost in loss record 87 of 1,034 at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by DEFWND_SetTextW (defwnd.c:134) by DefWindowProcW (defwnd.c:981) by StaticWndProc_common (static.c:520) by StaticWndProcW (static.c:630) by ??? (library.h:159) by call_window_proc (winproc.c:469) by WINPROC_call_window (winproc.c:2214) by call_window_proc (message.c:1635) by send_message (message.c:2482) by SendMessageW (message.c:2605) by WIN_CreateWindowEx (win.c:1340) by CreateWindowExW (win.c:1573) by DIALOG_CreateControls32 (dialog.c:276) by DIALOG_CreateIndirect (dialog.c:691) by DialogBoxIndirectParamAorW (dialog.c:871) by DialogBoxIndirectParamW (dialog.c:892) by MessageBoxIndirectW (msgbox.c:527) by MessageBoxExW (msgbox.c:451) by MessageBoxW (msgbox.c:406) We can reopen this bug if the leak turns out to be an actual 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.

1 9

[Bug 20686] New: Regression in latest git causes WOW screen corruption
by wine-bugs＠winehq.org 04 Dec '09

04 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20686 Summary: Regression in latest git causes WOW screen corruption Product: Wine Version: 1.1.29 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: celticht32(a)aol.com latest git causes screen corruption in WOW Git regression says : [cahrendt@stinky wine-git]$ git bisect bad 8e750b0ef6d810465d12566b6f03e6ce28b9451d is first bad commit commit 8e750b0ef6d810465d12566b6f03e6ce28b9451d Author: Rob Shearman <robertshearman(a)gmail.com> Date: Thu Nov 12 10:31:25 2009 +0000 widl: Include range types in constant BufferLength calculation for server function. :040000 040000 28e1f6d17f58a903618d98357718444b661f40ff 43265670cae4c487353cc73ee8b7d0d5f542df65 M tools [cahrendt@stinky wine-git]$ -- 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.

1 5

[Bug 20681] New: Microsoft Visual C++ .NET 2003 INTERNAL COMPILER ERROR: regression from 1.1.29
by wine-bugs＠winehq.org 04 Dec '09

04 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20681 Summary: Microsoft Visual C++ .NET 2003 INTERNAL COMPILER ERROR: regression from 1.1.29 Product: Wine Version: 1.1.32 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: ben(a)salilab.org Created an attachment (id=24704) --> (http://bugs.winehq.org/attachment.cgi?id=24704) test.cpp We are running wine on a 32-bit Fedora 11 machine, using cl (the MSVC++ .NET 2003 command line compiler) to build our software. Since we upgraded from wine-core-1.1.29-1.fc11.i586 to wine-core-1.1.32-1.fc11.i586, cl has stopped working: it fails with an internal compiler error. Downgrading to 1.1.29 fixes the problem. Using the attached test.cpp and boost 1.34 headers, running with wine-core-1.1.32-1.fc11.i586, we see the following: $ cl /c test.cpp test.cpp z:\synth1\home\ben\tmp\test.cpp(14) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\main.c', line 182) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information Microsoft (R) 32-bit C/C++ Standard Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. m Files\Microsoft Visual Studio .NET 2003\VC7\bin\cl: undname.c:189: str_array_push: Assertion `a->num < 32' failed. with 1.1.29 we see: $ cl /c test.cpp test.cpp Microsoft (R) 32-bit C/C++ Standard Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. Please let me know if you need more information. -- 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.

1 10

[Bug 20622] New: chromium's net_unittests.exe hangs in SSLClientSocketTest.Read
by wine-bugs＠winehq.org 04 Dec '09

04 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20622 Summary: chromium's net_unittests.exe hangs in SSLClientSocketTest.Read Product: Wine Version: 1.1.32 Platform: PC OS/Version: Linux Status: NEW Keywords: download, source Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com Chromium's SSLClientSocketTest.Read test outputs (ignoring repeated fixmes) [ RUN ] SSLClientSocketTest.Read fixme:crypt:CRYPT_CriticalExtensionsSupported unsupported critical extension "2.5.29.32" fixme:threadpool:RtlQueueWorkItem Flags 0x4 not supported fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority and then seems to hang. Five other SSL-related tests behave similarly: SSLClientSocketTest.Read_SmallChunks SSLClientSocketTest.Read_Interrupted HTTPSRequestTest.HTTPSExpiredTest HTTPSRequestTest.HTTPSGetTest HTTPSRequestTest.HTTPSMismatchedTest To repeat: $ wget http://kegel.com/wine/chromium/chromium-tests.tar.bz2 $ tar -xjvf chromium-tests.tar.bz2 $ sudo cp src/net/data/ssl/certificates/root_ca_cert.crt /usr/share/ca-certificates/ $ sudo vi /etc/ca-certificates.conf (and add the line root_ca_cert.crt) $ sudo update-ca-certificates $ # (or run juan's importer, http://bugs.winehq.org/show_bug.cgi?id=20370#c4 ) $ wine src/chrome/Debug/net_unittests.exe --gtest_filter=SSLClientSocketTest.Read I'll attach a +relay,+secur32,+crypt,+seh log. -- 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.

1 10

[Bug 20602] New: thread/cpu affinity not correct with multi core enabled source engine games
by wine-bugs＠winehq.org 04 Dec '09

04 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20602 Summary: thread/cpu affinity not correct with multi core enabled source engine games Product: Wine Version: 1.1.32 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fzielcke(a)z-51.de This is actually with current git HEAD de00535c13fba643c9c2bc178225be3cecafd92d not the 1.1.32 release. Even if I enable the Multi Core support in Day of Defeat:Source or Team Fortress 2, the cpu mask is set to one CPU. I checked /proc/($pgrep hl2.exe)/status and also run both in a window with top running in the background and visible P column (last used CPU). wine taskmgr shows an affinity of both CPUs. If I uncheck one and check one again then the main 2 threads needing CPU time run on both my cores. This is a huge increase in performance for me. For example in ctf_2fort on a well visited server I get only ~10-20 FPS on the bridge if there's fighting and the hl2 process is locked on 1 core. Whereas if they run on both, it's good playable and I think it's somewhat around ~40 FPS. It also works fine if I compile wineserver without HAVE_SCHED_SETAFFINITY I tried mat_queue_mode 2, too. mat_queue_mode -1 seems to be the default for multicore enabled. So even if TF2/DoD:S have a bug to still force a CPU affinity of 1, wine taskmgr should at least display it correctly. I use Debian sid + experimental. For compilation I use Debian 4.4.2-2 with CFLAGS="-march=native -pipe -O2" Hardware is Athlon64 X2 4600+, 2 GiB RAM and a Geforce GTS 250 with the 190.42 Nvidia proprietary drivers. -- 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.

1 19

[Bug 20517] New: temporary language switch causes permanent change of codepage
by wine-bugs＠winehq.org 04 Dec '09

04 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20517 Summary: temporary language switch causes permanent change of codepage Product: Wine Version: 1.1.30 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net For as long as I can remember (I'm sorry to report this now only), the sequence rm -rf .wine; wine winecfg; LANG=C wine winecfg; wine winecfg (assuming a default of LANG=de_DE.UTF-8 in Linux) provoked the following change in the registry against the initial setting: +[System\\CurrentControlSet\\Control\\Nls\\Codepage] 1251317004 "37"="" "ACP"="1252" -"OEMCP"="437" +"OEMCP"="850" This proves that something is not initialized consistently. This is clearly a bug and might cause seemingly non-deterministic faults in apps. I don't know whether this is related to the bug that I'm actually researching: some old multi-lingual French and German apps start in English when I expect them to start in French or German. On the Mac, the situation in the registry seems a little worse. Apple has a couple of fonts using native (non-ASCII) file names. Switching from the default German to the French locale (see bug #20377 on how to do this on the Mac) causes the following changes in addition to the above: -"Hiragino Mincho Pro (TrueType)"="Z:\\Library\\Fonts\\\x30d2\x30e9\x30ae\x30ce... +"Hiragino Mincho Pro (TrueType)"="Z:\\Library\\Fonts\\\xe3\x83\x92\xe3\x83\xa9... # The file name is ヒラギノ明朝 Pro W3.otf or similar. -"Locale"="00000407" +"Locale"="0000040c" -"sCountry"="Germany" +"sCountry"="France" -"sLanguage"="DEU" +"sLanguage"="FRA" I.e. the filename's encoding was changed. I don't know whether it's consistent with the codepage, but I see no reason why switching from German (UTF-8) to French (UTF-8) should cause Wine to change - the codepage or - filename encodings. Regards, Jörg Höhle -- 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.

1 9

[Bug 20516] New: Alt-F10 sent on press of F10 with wineconsole --backend=user
by wine-bugs＠winehq.org 04 Dec '09

04 Dec '09

http://bugs.winehq.org/show_bug.cgi?id=20516 Summary: Alt-F10 sent on press of F10 with wineconsole --backend=user 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: singularita(a)gmail.com I am using opensource FAR manager, run via "wineconsole --backend=user". In wine 1.1.32, when I press F10 (this key usually invokes dialog asking if you want to really quit FAR), Alt-F10 is sent to the program instead (Alt-F10 invokes the tree in FAR). Other F-keys (F1 .. F9, F11, F12) work normally. When I downgarded from 1.1.32 to 1.1.31, the bug disappeared and F10 started behaving normally. -- 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.

1 14

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs December 2009