Re: mscoree: Search for Mono in some predefined paths before using the registry. (try 2)
Vincent Povirk vinc...@codeweavers.com writes: +/* Last: the registry */ +return get_mono_path_from_registry(path); You probably want to check the registry first, to make it possible to override the global install if necessary. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 1/8] gameux/tests: Add test of storing and reading game statistics (try2)
W dniu 23.09.2010 15:40, (Marvin) pisze: Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5426 Your paranoid android. === WINEBUILD (build) === Make failed This is strange and I don't see any way how it would be connected with my patch. Error message says: make: /tools/winapi/make_filter: Command not found and when I was trying to submit patch to bot manually, it caused the same error. Does anyone know what's going on here? -- Best regards Mariusz Pluciński
Re: [PATCH 6/8] gameux: IGameStatistics::GetMaxValueLength implementation
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5430 Your paranoid android. === WINEBUILD (build) === Make failed
Re: configure: Detect resolver functionality on FreeBSD.
Tijl Coosemans t...@coosemans.org writes: @@ -1270,13 +1270,12 @@ AC_SUBST(RESOLVLIBS,) if test $ac_cv_header_resolv_h = yes then ac_save_LIBS=$LIBS -LIBS=$LIBS -lresolv -AC_LINK_IFELSE([AC_LANG_PROGRAM([[#ifdef HAVE_NETINET_IN_H -#include netinet/in.h -#endif -#include resolv.h]],[[res_init();]])], -[AC_DEFINE(HAVE_RESOLV, 1, [Define if you have the resolver library and header]) - RESOLVLIBS=-lresolv]) +AC_SEARCH_LIBS(res_init, resolv, +AC_DEFINE(HAVE_RESOLV, 1, [Define if you have the resolver library and header])) +case $ac_cv_search_res_init in + no*) ;; + *) RESOLVLIBS=$ac_cv_search_res_init ;; +esac This breaks on Linux. res_init() can be a macro. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 5/8] gameux: IGameStatistics::GetMaxNameLength implementation
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5429 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH 4/8] gameux: IGameStatistics::GetMaxCategoryLength implementation
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5428 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH 8/8] gameux: IGameStatistics::GetMaxStatsPerCategory implementation
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5432 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH 1/8] gameux/tests: Add test of storing and reading game statistics (try2)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5426 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [PATCH 3/8] gameux: Add stub of IGameStatistics interface implementation (resend)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5427 Your paranoid android. === WINEBUILD (build) === Make failed
Re: mscoree: Search for Mono in some predefined paths before using the registry. (try 2)
That was why I was checking c:\windows\mono first. On Thu, Sep 23, 2010 at 5:05 AM, Alexandre Julliard julli...@winehq.org wrote: Vincent Povirk vinc...@codeweavers.com writes: + /* Last: the registry */ + return get_mono_path_from_registry(path); You probably want to check the registry first, to make it possible to override the global install if necessary. -- Alexandre Julliard julli...@winehq.org
Re: Debugging 64-bit Wine Apps with winedbg
Hi, I'm not a winedbg expert but I think your mis-using it. As it's your software, you can compile it from source and add debug info. I know Visual Studio can create .pdb files but I don't know if winedbg can use it. Personally, I'm using gcc mingw with -g and that perfectly works. The easiest way is to install the linux package (e.g. mingw-w64 for the 64 bits version or mingw32 what I'm using) Then compile your software : (depends on your arch and the 32/64 bits version) $ i586-mingw32msvc-gcc test.c -g -o test.exe and run it through the debugger : $ /home/alex/Projects/wine-git/wine /home/alex/Projects/wine-git/programs/winedbg/winedbg.exe.so test.exe type break main or break WinMain on the console then return (you may have to select the proper main() ) (or break aFunctionName) cont to continue until your breakpoint is reached list to see the next lines of the code step to step in next to step over bt to have the backtrace quit to detach the process from the debugger and exit you can also type break followed by a line number to add a breakpoint on the specified line of the current debugged source file If you need more commands, G**gle is your friend. I hope that that will help you. --- If you have a page fault on create_alpha_bitmap, just type set $BreakOnFirstChance=0 first
Re: [PATCH 1/3] msxml3: Implement SelectionNamespaces property for XPath
Adam Martinson amartin...@codeweavers.com writes: Ignore the previous stuff from me, rebased split into a patch set. From bdc1ce7957ee1be31f4b39484285a164bc4ba6b2 Mon Sep 17 00:00:00 2001 From: Adam Martinson amartin...@codeweavers.com Date: Wed, 22 Sep 2010 14:02:47 -0500 Subject: [PATCH 1/3] msxml3: Implement SelectionNamespaces property for XPath It fails make test: ../../../tools/runtest -q -P wine -M msxml3.dll -T ../../.. -p msxml3_test.exe.so domdoc.c touch domdoc.ok XPath error : Invalid context position xmlXPathEval: evaluation failed XPath error : Undefined namespace prefix xmlXPathEval: evaluation failed XPath error : Undefined namespace prefix xmlXPathEval: evaluation failed XPath error : Undefined namespace prefix xmlXPathEval: evaluation failed domdoc.c:514: Test succeeded inside todo block: IXMLDOMNodeList_get_length(list, len) returned 0 domdoc.c:520: Test succeeded inside todo block: IXMLDOMNodeList_nextNode(list, node) returned 0 domdoc.c:469: Test succeeded inside todo block: IXMLDOMNode_get_nodeType(node, type) returned 0 domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:492: Test succeeded inside todo block: get_parentNode failed () domdoc.c:469: Test succeeded inside todo block: IXMLDOMNode_get_nodeType(node, type) returned 0 domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:492: Test succeeded inside todo block: get_parentNode failed () domdoc.c:469: Test succeeded inside todo block: IXMLDOMNode_get_nodeType(node, type) returned 0 domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:492: Test succeeded inside todo block: get_parentNode failed () domdoc.c:469: Test succeeded inside todo block: IXMLDOMNode_get_nodeType(node, type) returned 0 domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:492: Test succeeded inside todo block: get_parentNode failed () domdoc.c:469: Test succeeded inside todo block: IXMLDOMNode_get_nodeType(node, type) returned 0 domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:492: Test succeeded inside todo block: get_parentNode failed () domdoc.c:469: Test succeeded inside todo block: IXMLDOMNode_get_nodeType(node, type) returned 0 domdoc.c:446: Test succeeded inside todo block: get_previousSibling failed domdoc.c:492: Test succeeded inside todo block: get_parentNode failed (0001) XPath error : Undefined namespace prefix xmlXPathEval: evaluation failed XPath error : Undefined namespace prefix xmlXPathEval: evaluation failed wine: Unhandled page fault on write access to 0x at address 0x7bc48a27 (thread 001c), starting debugger... err:seh:raise_exception Unhandled exception code c005 flags 0 addr 0x7bc49c6b make: *** [domdoc.ok] Error 5 -- Alexandre Julliard julli...@winehq.org
Re: Debugging 64-bit Wine Apps with winedbg
On 23/09/10 06:51, Tom Grubbe wrote: problem seems to be getting any kind of stack trace information from the 64-bit winedbg. This used to work with the 32-bit version of winedbg. I can confirm that wine64 winedbg can not produce valid backtraces for multi-threaded programs (.exe + .pdb) generated by the VS2005 64-bit compiler. I get something like the following: Backtracing for thread 001a in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68ceb3c7a0) Backtracing for thread 0019 in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68cec4c7a0) Backtracing for thread 0018 in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68ced5c320) Backtracing for thread 0009 in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68cef7deb0) 0x7f0d2737b5ab __libc_read+0x2b in libpthread.so.0: syscall Testing on Gentoo x86_64, with wine 1.3.2. Identical source code compiled with VS2005 32-bit compiler running under wine32 produces valid backtraces, although they suffer from bug #20617 * Setting WINEDEBUG to several debug channels has helped some but is difficult to sift through all the noise I don't get much joy from WINEDEBUG output because the crash I encounter appears to be in a DLL initialisation routine called / calling code from Microsoft.VC80.CRT redist code. I can't use the wine msvcrt/msvcp implementations because they are missing implementations for several functions. So any info on strategies to debug 64-bit Wine applications is welcome I would also like to hear any tips for debugging under wine64. I'm finding that even the minidump files produced by wine64 are not much use in VS2005 or VS2008. At least the minidumps from wine32 can provide a little bit of info when loaded into VS2008 debugger. I'm happy to provide test source code, 64-bit and 32-bit binaries and matching PDB files, if anyone is interested in looking at the issue. Cheers, Peter Urbanec
RE: Debugging 64-bit Wine Apps with winedbg
It's good to know someone else is also seeing these problems. In fact here's
my tiny test app that should produce a backtrace but does not with winedbg
64-bit:
% cat Crash.cpp
#include stdio.h
extern C void crash_func()
{
char* p = 0;
*p = 'x';
}
extern C int main()
{
crash_func();
return 0;
}
% wine64 /hex1/test/Crash/x64/Debug/Crash.exe
fixme:heap:HeapSetInformation 0x2ad17069 0 0x2ad17068fcb0 4
wine: Unhandled page fault on write access to 0x at address 0x140001046
(thread 0009), starting debugger...
Unhandled exception: page fault on write access to 0x in 64-bit code
(0x000140001046).
Register dump:
rip:000140001046 rsp:2ad17068fca0 rbp:000140001220 eflags:00010206
( R- -- I - -P- )
rax: rbx:2ad16cab9000 rcx:
rdx:2ad170691230
rsi: rdi:2ad17068fcb0 r8:2ad1706919f0
r9:0004 r10:2ad170691290
r11:10341ff0 r12: r13:2ad16cc72860
r14:000140f0 r15:2ad16cabc000
Stack dump:
0x2ad17068fca0:
0x2ad17068fcb0: 2ad17068fce0 00014000107f
0x2ad17068fcc0:
0x2ad17068fcd0:
0x2ad17068fce0: 2ad16cfa5320 0001400013d2
0x2ad17068fcf0: 00010001 000140006220
0x2ad17068fd00: 2ad16cab9000 0001400018f5
0x2ad17068fd10:
0x2ad17068fd20: 2ad17069
0x2ad17068fd30: 5b5ac005
0x2ad17068fd40: 2ad17068e9e8
0x2ad17068fd50: 00014000122e
Backtrace:
0x000140001046: movb$0x78,(%rax)
Modules:
Module Address Debug info Name (14
modules)
PE 1020-1034f000 Deferredmsvcr90d
PE 4000-4000e000 Deferredcrash
ELF 7be0-7c102000 Deferredwine-loader
ELF 3bdc20- 3bdc41d000 Deferred
ld-linux-x86-64.so.2
ELF 3bdc60- 3bdc957000 Deferredlibc.so.6
ELF 3bdca0- 3bdcc83000 Deferredlibm.so.6
ELF 3bdce0- 3bdd004000 Deferredlibdl.so.2
ELF 3bdd20- 3bdd41b000 Deferredlibpthread.so.0
ELF 3be120- 3be140e000 Deferredlibgcc_s.so.1
ELF 2ad16c07d000-2ad16c3ad000 Deferredlibwine.so.1
ELF 2ad16c3d4000-2ad16c6b9000 Deferredntdllelf
\-PE 2ad16c3f-2ad16c6b9000 \ ntdll
ELF 2ad16cc05000-2ad16cfa6000 Deferredkernel32elf
\-PE 2ad16cc2-2ad16cfa6000 \ kernel32
Threads:
process tid prio (all id:s are in hex)
0008 (D) Z:\hex1\test\Crash\x64\Debug\Crash.exe
00090 ==
000e services.exe
00160
00150
00140
00100
000f0
0011 winedevice.exe
00170
00130
00120
0018 explorer.exe
00190
Backtrace:
err:seh:setup_exception nested exception on signal stack in thread 0009 eip
003bdd20bc05 esp 2ad16cabef68 stack 0x2ad170592000-0x2ad17069
--Tom Grubbe x2609
-Original Message-
From: Peter Urbanec [mailto:winehq@urbanec.net]
Sent: Thursday, September 23, 2010 10:05 AM
To: wine-devel@winehq.org
Subject: Re: Debugging 64-bit Wine Apps with winedbg
On 23/09/10 06:51, Tom Grubbe wrote:
problem seems to be getting any kind of stack trace information from
the 64-bit winedbg. This used to work with the 32-bit version of winedbg.
I can confirm that wine64 winedbg can not produce valid backtraces for
multi-threaded programs (.exe + .pdb) generated by the VS2005 64-bit
compiler.
I get something like the following:
Backtracing for thread 001a in process 0008 (Z:\amd64\MultipleThreads.exe):
Backtrace:
=0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0
(0x7f68ceb3c7a0)
Backtracing for thread 0019 in process 0008 (Z:\amd64\MultipleThreads.exe):
Backtrace:
=0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0
(0x7f68cec4c7a0)
Backtracing for thread 0018 in process 0008 (Z:\amd64\MultipleThreads.exe):
Backtrace:
=0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0
(0x7f68ced5c320)
Backtracing for thread 0009 in process 0008 (Z:\amd64\MultipleThreads.exe):
Backtrace:
=0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0
(0x7f68cef7deb0)
0x7f0d2737b5ab __libc_read+0x2b in libpthread.so.0: syscall
Testing on Gentoo x86_64, with wine 1.3.2. Identical source code
compiled with VS2005 32-bit compiler running under wine32 produces valid
backtraces,
Re: Debugging 64-bit Wine Apps with winedbg
I'm happy to provide test source code, 64-bit and 32-bit binaries and matching PDB files, if anyone is interested in looking at the issue. sure send me the .exe+pdb (+source) I'll have a look at it I only tested winedbg on 64bit with gcc A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
ie6 download failing
Looks like Microsoft has been letting the ie6 download servers rot. Over the last few weeks, 'winetricks ie6' has been hanging occasionally, and today, it's failing right off the bat with wget http://www.microsoft.com/windows/ie/ie6sp1/download/rtw/x86/ie6sites.dat ... Resolving www.microsoft.com... 65.55.12.249 Connecting to www.microsoft.com|65.55.12.249|:80... connected. HTTP request sent, awaiting response... 500 Internal Server Error Personally, I think it's great that ie6 is getting the shaft, but it does make life with wine a bit more difficult. I hope this error is transient.
Re: ie6 download failing
On 23 September 2010 23:01, Dan Kegel d...@kegel.com wrote: Looks like Microsoft has been letting the ie6 download servers rot. Over the last few weeks, 'winetricks ie6' has been hanging occasionally, and today, it's failing right off the bat with wget http://www.microsoft.com/windows/ie/ie6sp1/download/rtw/x86/ie6sites.dat ... Resolving www.microsoft.com... 65.55.12.249 Connecting to www.microsoft.com|65.55.12.249|:80... connected. HTTP request sent, awaiting response... 500 Internal Server Error Personally, I think it's great that ie6 is getting the shaft, but it does make life with wine a bit more difficult. I hope this error is transient. If this is a permanent thing it is both good and bad news. Good news in that it is a step closer to a better, safer web experience (although people will still be able to get IE6 on the default XP and 2003 installs, but then again probably not with the latest service packs applied). I can understand why Microsoft would want to do this. Bad news in that IE6 is the version of IE that works the best with Wine and is critical (at the moment) for applications that use the WebBrowser component to render content. In particular, the Big Fish Games client uses a web interface and uses the WebBrowser control to render that content. With the Wine implementation it displays nothing (just a white area with a scroll bar); with IE7 it displays something similar and a lot of script errors and with IE6 it works. I have an installed version of this, so for this application I am ok, but for others that are freshly installing it they are going to have problems, which only tend to revolve around the client and not the games themselves. The most flaky part of Wine I have seen so far is the shdocvw/mshtml/jscript/WebBrowserControl/IE support. This is not because wine is bad, it is just that there are chunks of functionality in that area that Wine has not implemented/fully implemented and applications are relying on that behaviour. I have also seen the behaviour of these applications completely change due to the slightest change in these areas (even though those changes may be correct). So, there are 2 ways to resolve this: 1/ get the Wine+Gecko implementation of the various APIs to the point where they can run more of the applications using the WebControl hosting (which I can imagine is a significant chunk of work); or 2/ resolve the issues with installing IE7 (and likely IE8) so that it works with WebControl hosting applications. Longer term I can see Microsoft dropping IE7. They will also drop IE8, but that won't be for a while yet (at least until they finally stop XP). Then there is IE9 which is in beta at the moment, but does not install on Wine at the moment: it needs several Vista and later DLLs and will need better DX10/11 support as well as Direct2D and DirectWrite support. Interestingly, since Mozilla support the Direct2D and DirectWrite APIs their browser can be a test platform for the implementation and having an understanding of how the bits and pieces fit together. - Reece
Can we please have a packaging bugzilla component and not close packaging bugs?
Sometimes it's not 100% clear whether a problem is in the packaging or upstream part of Wine, and packaging bugs are just as much legitimate problems as normal Wine bugs. WineHQ is often the best place to have that discussion as 1) more than one packager would see it, and 2) if we're doing something wrong a developer can tell us too. I think we discussed this idea last wineconf informally, although I'm not sure anyone committed to making it happen. Thanks, Scott Ritchie
Re: Debugging 64-bit Wine Apps with winedbg
On 24/09/10 06:43, Eric Pouech wrote: sure send me the .exe+pdb (+source) I'll have a look at it Source and binaries sent to Eric in private, so that the list isn't polluted with megabytes of binaries. If anyone else is interested in having a copy, please let me know and I'll forward it in private. Cheers, Peter Urbanec
