March 2011 - Wine-Devel - list.winehq.org

Why am I getting create_view out of memory?

by Peter Urbanec

I've got a heavily multithreaded 64-bit app that uses a lot of memory. After a while, I see this: fixme:virtual:create_view out of memory in virtual heap for 0x7f94465b0000-0x7f94466d6000 fixme:virtual:create_view out of memory in virtual heap for 0x7f9446640000-0x7f94466d3000 fixme:virtual:create_view out of memory in virtual heap for 0x7f9446690000-0x7f94466da000 fixme:virtual:create_view out of memory in virtual heap for 0x7f94466b0000-0x7f94466d5000 Could someone please explain to me what's going on here? Quick look at the code indicates that there is a 4MB heap used for "views" (I have no idea what these are) and presumably that heap is exhausted. Is this likely a resource leak somewhere? Some memory stats on the app I'm running: Process: PeakVirtualSize 3f2baf000, VirtualSize 3eccd0000 PeakWorkingSetSize 3762d6000, WorkingSetSize 3689ac000 PeakPagefileUsage 3f2baf000, PagefileUsage 3eccd0000 Global: TotalPhys 3eb4f2000, AvailPhys 0c4d8000 TotalPageFile 66b984000, AvailPageFile 1733eb000 TotalVirtual 7ffffffdffff, AvailVirtual 7ffc1330ffff Cheers, Peter Urbanec

March 3, 2011

Re: USB Osciloscope

by Martin Owens

On Tue, 2011-03-01 at 17:09 -0700, Archie Robertson wrote: > so If somebody could point me in the > right direction I should be able to get this working.

March 2, 2011

Re: [PATCH] shldocvw: Fixed typo = vs == (Coverity)

by Marcus Meissner

On Fri, Feb 25, 2011 at 09:30:21PM +0100, Eric Pouech wrote: > Le 25/02/2011 14:16, Marcus Meissner a écrit : > >CID1801 > >--- > > dlls/shdocvw/shlinstobj.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > >diff --git a/dlls/shdocvw/shlinstobj.c b/dlls/shdocvw/shlinstobj.c > >index d272c91..067e678 100644 > >--- a/dlls/shdocvw/shlinstobj.c > >+++ b/dlls/shdocvw/shlinstobj.c > >@@ -376,7 +376,7 @@ HRESULT SHDOCVW_GetShellInstanceObjectClassObject(REFCLSID rclsid, REFIID riid, > > > > /* Figure if there is an 'Instance' subkey for the given CLSID and acquire a handle. */ > > if (!StringFromGUID2(rclsid, wszInstanceKey + 6, CHARS_IN_GUID) || > >- !(wszInstanceKey[5+CHARS_IN_GUID]='\\') || /* Repair the null-termination. */ > >+ !(wszInstanceKey[5+CHARS_IN_GUID] == '\\') || /* Repair the null-termination. */ > > ERROR_SUCCESS != RegOpenKeyExW(HKEY_CLASSES_ROOT, wszInstanceKey, 0, KEY_READ,&hInstanceKey)) > > { > > /* If there is no 'Instance' subkey, then it's not a Shell Instance Object. */ > are you sure about the fix ? > it looks like it's intentional that the test always succeed (it just > replaces the null termination char written in StringFromGUID2 with a > '\\') > (and this would explain the comment as well ;-) > I'm not familiar with the code... just being suspicious This was right, I fixed it. :) Ciao, Marcus

March 2, 2011

Re: WineHQ Bug 26271

by Juan Lang

> Wine is big and those patches cover only a small aspect. E.g. if a > distribution reports a crypt32 bug it doesn't matter if they use > winepulse.drv or not, right? I'm just opposing the blanket "reject all" > distribution Wine binaries created from modified source. For the Wine > aspects modified by the distributions the distributions will have to do > the heavy lifting. But the way we word that matters too. And of course > we are always free to request a bug reporter to try to reproduce the bug > with unmodified/latest Wine source. Ah. Yes, you're right. The nuances of your disagreement escaped me, as this bug was clearly in an area affected by the unsupported patches. Thanks for the clarification. --Juan

March 2, 2011

Re: WineHQ Bug 26271

by Michael Stefaniuc

Hello Juan, Juan Lang wrote: >>> Once again, packages with custom patches can't be supported through WineHQ >>> bugzilla for obvious reasons. If the packager knows what he/she is dooing by >> I disagree with this statement. Each distribution modifies the upstream >> Wine in one way or the other. And a blanket "Screw you, use upstream >> Wine if you want support" doesn't cut it. The distributions are for us >> the main consumers of Wine and we should help them provide a good Wine >> experience to their users. > > I don't understand. How are we supposed to support our distributions > when they include unsupported patches? Wine is big and those patches cover only a small aspect. E.g. if a distribution reports a crypt32 bug it doesn't matter if they use winepulse.drv or not, right? I'm just opposing the blanket "reject all" distribution Wine binaries created from modified source. For the Wine aspects modified by the distributions the distributions will have to do the heavy lifting. But the way we word that matters too. And of course we are always free to request a bug reporter to try to reproduce the bug with unmodified/latest Wine source. bye michael

March 2, 2011

Re: USB Osciloscope

by Damjan Jovanovic

On Wed, Mar 2, 2011 at 12:56 PM, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: >>>>>> "Shachar" == Shachar Shemesh <shachar(a)shemesh.biz> writes: > Also > Damjan Jovanovic Jan 23 91/4337 "USB architecture: driver loading question" > tried to take up the subject, again with no feedback. For the record, I haven't had much feedback on that "driver loading question" either, so I've had little to go on. But since I see many people are interested, I am increasing the priority of that project. > Linux users in the elektronic area would love to see Wine supporting USB > drivers... I've been waiting since 2004... > Archie Damjan Jovanovic

March 2, 2011

Re: WineHQ Bug 26271

by Juan Lang

Hello Michael, >> Once again, packages with custom patches can't be supported through WineHQ >> bugzilla for obvious reasons. If the packager knows what he/she is dooing by > I disagree with this statement. Each distribution modifies the upstream > Wine in one way or the other. And a blanket "Screw you, use upstream > Wine if you want support" doesn't cut it. The distributions are for us > the main consumers of Wine and we should help them provide a good Wine > experience to their users. I don't understand. How are we supposed to support our distributions when they include unsupported patches? --Juan

March 2, 2011

Re: WineHQ Bug 26271

by Andreas Bierfert

On Wed, 2011-03-02 at 17:15 +0100, Michael Stefaniuc wrote: > I disagree with this statement. Each distribution modifies the > upstream > Wine in one way or the other. And a blanket "Screw you, use upstream > Wine if you want support" doesn't cut it. The distributions are for us > the main consumers of Wine and we should help them provide a good Wine > experience to their users. Thanks. > Of course in this specific case aka bug 26271 we cannot help as it > involves winepulse.drv which is an unsupported outside patch As stated in 26271 the problem also occurs if build without the pulse patches. Help/insight in fixing this would be appreciated. - Andreas -- BRef Andreas Bierfert, M.Sc. | phone: +49 6897 1721738 | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | fax: +49 6897 1722828 | signed/encrypted http://lowlatency.de | cell: +49 170 9665206 | mail preferred

March 2, 2011

Re: WineHQ Bug 26271

by Michael Stefaniuc

Hello Dmitry, Dmitry Timoshkov wrote: > Andreas Bierfert <andreas.bierfert(a)lowlatency.de> wrote: > >> could you please stop arguing about the validity of the bug. What you >> are stating in comment 6 is really not exclusive. The Fedora wine >> packages are in fact 'prepackaged binary'. > > Using the term 'prepackaged binary' doesn't make the package suddenly valid > for WineHQ bugzilla, since it clearly contains not supported patches. Same > applies for instance to crossover, ies4linux, wineskin or any other. > >> For the Fedora users pulse support in wine is an important feature. This >> is why the patches are in the Fedora build in the first place. I'd much >> rather have them included with upstream... Maybe sometime wine will gain >> openal support for audio input/output and this issue will go away. > > Once again, packages with custom patches can't be supported through WineHQ > bugzilla for obvious reasons. If the packager knows what he/she is dooing by I disagree with this statement. Each distribution modifies the upstream Wine in one way or the other. And a blanket "Screw you, use upstream Wine if you want support" doesn't cut it. The distributions are for us the main consumers of Wine and we should help them provide a good Wine experience to their users. Of course in this specific case aka bug 26271 we cannot help as it involves winepulse.drv which is an unsupported outside patch. > including such patches - he/she should take the full resposibility for that, > including accepting bug reports for his package. If he/she doesn't want to > carry the support burden then using Wine source without any custom patches > is the way to go. bye michael

March 2, 2011

Re: t2embed: Add stub for _TTEmbedFont

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > diff --git a/dlls/t2embed/t2embed.spec b/dlls/t2embed/t2embed.spec > index 2566fa2..729a71b 100644 > --- a/dlls/t2embed/t2embed.spec > +++ b/dlls/t2embed/t2embed.spec > @@ -11,7 +11,7 @@ > @ stub TTRunValidationTests > @ stub _TTCharToUnicode(a)24 > @ stub _TTDeleteEmbeddedFont(a)12 > -@ stub _TTEmbedFont(a)44 > +@ stdcall _TTEmbedFont(ptr long long ptr ptr ptr ptr ptr long long ptr) This change is not correct, the exported name is _TTEmbedFont(a)44. -- Dmitry.

March 2, 2011