October 2006 - Wine-Devel - list.winehq.org

Re: Mem usage in Mac OSX

by Ken Thomases

On Oct 2, 2006, at 12:49 PM, Robert Shearman wrote: > Nick Burns wrote: >> All the following have this VM ~=4GB on startup -- its not a >> leaking problem... (afaict) >> >> OGL/D3D -- WinRAR, GTAVC, Tribes2, (FlatOutDemo -- even thou it >> dies on startup now -- still gets to ~4GB), SHOGO >> >> NON-GL -- cmd (not even using X11), winecfg, StreamDown, MS VC++ >> 6, MS+Connentix VPC (even thou it uses a driver and will not start >> correctly), Shogo (start screen) >> >> --- >> It just plain takes too much mem -- then dies due to the OS >> saying ....no more.... >> (I will have to test top at some point...) >> >> Does Linux have the same mem problem? -- does top show like 4GB of >> VSIZE on app start? > > The numbers seem bogus since 32-bit apps can only take up 4Gb of > VM. Wine does reserve 1.5Gb of VM on startup to ensure no system > libraries are present in the area needed for Win32 apps and libraries. And Mac OS X reserves another ~0.5GB of the VM address space for "submaps". These are areas of VM that are reserved for the system libraries to be loaded into. See the "-submap" explanation in the man page for the vmmap tool: <http://developer.apple.com/ documentation/Darwin/Reference/ManPages/man1/vmmap.1.html>. In fact, vmmap is useful for investigating this issue. The command "vmmap -interleaved -w -submap <pid>" will show you the submaps. Note that the submap address ranges overlap the specific loaded areas that follow them. Adding "-allSplitLibs" will show the way the submaps are divided up among libraries that aren't loaded but might be. This also includes the unused split libraries in the subtotals at the end of the report. Running notepad and applying vmmap shows only about 95MB of unused split libs. So, apparently, the half gig in submaps is actually mostly used. The other really big chunk of VM (after Wine) is labeled as "STACK GUARD". I believe the intent of STACK GUARD space is to generate exceptions (EXC_BAD_ACCESS / SIGSEGV) if a stack grows beyond its pre- allocated bounds. It's another 1.5GB! This seems like the real culprit. I think STACK GUARD pages should only show up in single- page areas (4K) on either side of a stack. I'm seeing huge areas (~240MB, ~250MB, and ~1GB). There's only one actual stack showing. It's 8MB, between the 250MB guard and the 1GB guard. Checking a normal Mac app (Mail) shows no such huge STACK GUARD areas -- just a single 4K page below each actual stack. I have no idea what's creating these huge stack guard areas. -Ken

Oct. 3, 2006

Re: dlls/user/tests/win.c fix

by Juan Lang

Hi Dmitry, --- Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Does moving flush_events() a bit further like in the attached patch > help? It seems to help a bit, it fails about 50% of the time just by moving it. > If it doesn't, please try to change 100 in flush_events to 200 or even > more and see if that helps. 200 works great for me--no failures from the first try, and no failures after repeated attempts. Thanks! --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Oct. 3, 2006

Re: dlls/user/tests/win.c fix

by Dmitry Timoshkov

"Juan Lang" <juan_lang(a)yahoo.com> wrote: > win.c:2414: Test failed: message 000f available > win.c:2422: Test failed: message 000f available > win.c:2430: Test failed: message 000f available > make: *** [win.ok] Error 3 > > On the fourth run it succeeded. I know you know that these are WM_PAINT > again. Does moving flush_events() a bit further like in the attached patch help? If it doesn't, please try to change 100 in flush_events to 200 or even more and see if that helps. -- Dmitry.

Oct. 3, 2006

Re: KERNEL: honor additional DLL search paths under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths

by Vitaliy Margolen

Alex Villacís Lasso wrote: > Mike McCormack escribió: >> Alex Villacís Lasso wrote: >> >>> Changelog: >>> * Check under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App >>> Paths\\EXENAME.EXE for >>> additional directory locations to search for DLLs. Fixes Dreamweaver >>> MX 6.0. >> >> This change is incorrect. The App Pathes key is checked by >> ShellExecute, not by CreateProcess. >> >> Try running "wine start exename.exe" >> >> Mike >> > [alex(a)srv64 Dreamweaver MX]$ wine start Dreamweaver.exe > L"C:\\Archivos de programa\\Macromedia\\Dreamweaver > MX\\Configuration\\JSExtensions\\DWEMLaunch.dll") not found > > Dreamweaver still can't find the DLL without my patch, even with the > "start" command, as demonstrated in the previous trace. Did you mean > that my patch *should* have placed the check in ShellExecute? Does > cmd.exe from Windows XP use CreateProcess or ShellExecute? I plan to > install DreamWeaver MX 6 inside a virtual machine, to check actual > behavior. If cmd.exe uses CreateProcess and your statement is correct, > then the error message should also appear when Dreamweaver.exe is > executed from the command line. > You have to run it from other directory. Actually from _any_ directory but the one that exe is in. Don't ask me - ask m$ why they came up with this sort of .... stuff. Btw it will fail on win exactly the same way. Vitaliy

Oct. 3, 2006

Re: compiling wine for amd64 on ubuntu dapper 6.06

by Neil Skrypuch

On Monday, October 02, 2006 10:28, Gerald Britton wrote: > Is there a command to verify if the libs are 32- or 64-bit? Try file: neil(a)x2-42 ~ $ file /lib/libz.so.1.2.3 /lib/libz.so.1.2.3: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped neil(a)x2-42 ~ $ file /emul/linux/x86/lib/libz.so.1.2.3 /emul/linux/x86/lib/libz.so.1.2.3: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped - Neil

Oct. 3, 2006

Re: KERNEL: honor additional DLL search paths under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths

by Alex Villacís Lasso

Mike McCormack escribió: > Alex Villacís Lasso wrote: > >> Changelog: >> * Check under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App >> Paths\\EXENAME.EXE for >> additional directory locations to search for DLLs. Fixes Dreamweaver >> MX 6.0. > > This change is incorrect. The App Pathes key is checked by > ShellExecute, not by CreateProcess. > > Try running "wine start exename.exe" > > Mike > [alex(a)srv64 Dreamweaver MX]$ wine start Dreamweaver.exe fixme:exec:SHELL_execute flags ignored: 0x00000500 [alex(a)srv64 Dreamweaver MX]$ fixme:ole:CoRegisterMessageFilter message filter has been registered, but will not be used fixme:system:SystemParametersInfoW Unimplemented action: 65 (SPI_SETSOUNDSENTRY)fixme:shell:SHGetFileInfoW set icon to shell size, stub fixme:shell:SHGetFileInfoW set icon to shell size, stub err:x11drv:X11DRV_CreateWindow invalid window height -2 err:x11drv:X11DRV_CreateWindow invalid window height -4 err:x11drv:X11DRV_CreateWindow invalid window height -2 err:x11drv:X11DRV_CreateWindow invalid window height -2 fixme:imm:ImmReleaseContext (0x101cc, 0x159978): stub fixme:imm:ImmReleaseContext (0x101cc, 0x159978): stub fixme:imm:ImmReleaseContext (0x101cc, 0x159978): stub fixme:imm:ImmReleaseContext (0x101cc, 0x159978): stub fixme:imm:ImmReleaseContext (0x101cc, 0x159978): stub err:module:import_dll Library Gemstone.dll (which is needed by L"C:\\Archivos de programa\\Macromedia\\Dreamweaver MX\\Configuration\\JSExtensions\\DWEMLaunch.dll") not found fixme:imm:ImmReleaseContext (0x101cc, 0x159978): stub fixme:imm:ImmReleaseContext (0x101cc, 0x159978): stub fixme:imm:ImmReleaseContext (0x101cc, 0x159978): stub fixme:imm:ImmReleaseContext (0x101cc, 0x159978): stub Dreamweaver still can't find the DLL without my patch, even with the "start" command, as demonstrated in the previous trace. Did you mean that my patch *should* have placed the check in ShellExecute? Does cmd.exe from Windows XP use CreateProcess or ShellExecute? I plan to install DreamWeaver MX 6 inside a virtual machine, to check actual behavior. If cmd.exe uses CreateProcess and your statement is correct, then the error message should also appear when Dreamweaver.exe is executed from the command line. -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.

Oct. 3, 2006

Re: KERNEL: honor additional DLL search paths under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths

by Mike McCormack

Alex Villacís Lasso wrote: > Changelog: > * Check under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App > Paths\\EXENAME.EXE for > additional directory locations to search for DLLs. Fixes Dreamweaver MX > 6.0. This change is incorrect. The App Pathes key is checked by ShellExecute, not by CreateProcess. Try running "wine start exename.exe" Mike

Oct. 3, 2006

Re: AMD64 compilation successful; still not working

by Scott Ritchie

On latest Debian (or at least Ubuntu), you have to force compile without the stack protector on by doing -fno-stack-protector. See this bug: http://bugs.winehq.org/show_bug.cgi?id=6035 That said, I don't actually know if that's the issue you're running into. Thanks, Scott Ritchie On Mon, 2006-10-02 at 23:07 +0200, Alexander K. Seewald wrote: > Hi, > > I've managed to compile the current CVS version under AMD64, > according to the WineOn64bit-Wiki for Debian. So far, so good. > > However, all tests fail and starting wine gives an error code of 2. > --version gives no output. wine-kthread gives an error code of 139 > (segmentation violation), wine-pthread seems to work. Debugging wine > shows that the error appears when execve'ing (should have been > somewhat obvious ;-) > > When debugging wine-kthread, I get the following error on the first > line of code: > 0x557721ba in __libc_pthread_init () from /emul/ia32-linux/lib/tls/libc.so.6 > > Interestingly, my libc.so.6 link points to libc-2.3.2.so. Hope that > is ok... it is defined in the ia32-libc6 debian package from stable. > :-> > > Might this have something to do with my 4GB of memory? I am open for > suggestions... > > Best, > Alex

Oct. 2, 2006

Re: Request for Test: exception handling test

by Stefan Leichter

Am Thursday 01 January 1970 01:00 schrieb Marcus Meissner: > Hi, > > Can someone with ability to run the testsuite on Windows please test > the following new 2 testcases under Windows? > > They succeed in WINE now, but I wonder if they will work in Windows. > > Ciao, Marcus Hi, i don't get any new error on win2k. Attached is the logging of the modified test target. Bye Stefan

Oct. 2, 2006

AMD64 compilation successful; still not working

by Alexander K. Seewald

Hi, I've managed to compile the current CVS version under AMD64, according to the WineOn64bit-Wiki for Debian. So far, so good. However, all tests fail and starting wine gives an error code of 2. --version gives no output. wine-kthread gives an error code of 139 (segmentation violation), wine-pthread seems to work. Debugging wine shows that the error appears when execve'ing (should have been somewhat obvious ;-) When debugging wine-kthread, I get the following error on the first line of code: 0x557721ba in __libc_pthread_init () from /emul/ia32-linux/lib/tls/libc.so.6 Interestingly, my libc.so.6 link points to libc-2.3.2.so. Hope that is ok... it is defined in the ia32-libc6 debian package from stable. :-> Might this have something to do with my 4GB of memory? I am open for suggestions... Best, Alex -- Dr. Alexander K. Seewald GE Money Bank, Analytics/CRM +43(664)1106886 ------------------------------------------------ Information wants to be free; Information also wants to be expensive (S.Brant) --------------- alex.seewald.at ----------------

Oct. 2, 2006