December 2012 - Wine-Devel - list.winehq.org

Re: wine-1.5.20 reversion compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole

by Frédéric Delanoy

On Fri, Dec 28, 2012 at 11:54 AM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > On 2012-12-28 10:44+0100 Frédéric Delanoy wrote: > >> On Mon, Dec 24, 2012 at 8:58 AM, Alan W. Irwin >> <irwin(a)beluga.phys.uvic.ca> wrote: >>> >>> On 2012-12-23 21:25-0600 Austin English wrote: >>> >>>> On Dec 23, 2012 7:22 PM, "Alan W. Irwin" <irwin(a)beluga.phys.uvic.ca> >>>> wrote: >>>>> >>>>> The subject line pretty much says it all. Running MinGW/gcc under >>>>> wineconsole for any simple test programme should demonstrate the issue >>>>> for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large >>>>> selection of 1.5.x and MinGW versions I have tried over the last year >>>>> or so. >>>>> >>>>> I would be happy to supply more details if there is any difficulty >>>>> replicating this reversion. >>>>> >>>>> Alan >>>> >>>> Please run a regression test and file a bug at http://bugs.winehq.org. >>> >>> No thank you. >> >> Why would anyone help you if you fail to do your homework? > > The shoe is on the other foot. I am trying to help Wine developers > assuming they have an interest in fixing obvious problems in their > code no matter how informally such problems are pointed out. > > This bug should be easy to replicate. Try to compile any C programme > (e.g., a "Hello, world" programme) with MinGW-4.7.0 under wine-1.5.20 > and that compiler segfaults. Do the same under wine-1.5.19, and there > is no such problem. That's all that should be required to not only > replicate the bug but also demonstrate the reversion. Meanwhile, I am > happy to stick with 1.5.19 until some Wine developer takes > responsibility for getting this regression fixed. I think that creating a bug would have taken less time than writing your emails, and be more helpful on the long run (this thread will be archived like others, and be mostly forgotten, unlike bugs in bugzilla) > If anybody tries such a test, and doesn't see the issue, then > as I said before I am willing to supply more details. > > By the way, informal bug reports reported on mailing lists have been > quite helpful to me in the past for my own software projects. I also > have seen a number of projects spend an inordinate amount of time with > bug triage rather than actually fixing the code. Wine is a big project. What applies to a small/medium project doesn't necessarily apply here. If everybody started reporting bugs in emails, that would quickly become unmanageable. > So I welcome > informal bug reports for my own projects especially when an issue is > easy to replicate. It appears you do not personally welcome such > informal reports, but hopefully other wine developers are not so > inflexible for obvious problems like this one is. It's not so much that I don't welcome informal reports (they can be helpful of course), but I didn't like the tone of your inital reply. It sounded to me like: "Have someone fix my bug quickly, but I don't want to waste time reporting it correcty ["go through a bunch of Wine bug-reporting hoops"]... so do all the work yourself". That isn't a nice way to ask for support IMHO, especially for other people volunteering their time on Wine, and who may also have other projects of their own. Also, you didn't probably pay a cent for your wine version, so don't expect people to prioritize the issues you encounter above all others, which may be equally important. Other users have issues with wine but they don't generally complain as loudly as you did. > Alan Frédéric

Dec. 28, 2012

Re: wine-1.5.20 reversion compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole

by Alan W. Irwin

On 2012-12-28 10:44+0100 Frédéric Delanoy wrote: > On Mon, Dec 24, 2012 at 8:58 AM, Alan W. Irwin > <irwin(a)beluga.phys.uvic.ca> wrote: >> On 2012-12-23 21:25-0600 Austin English wrote: >> >>> On Dec 23, 2012 7:22 PM, "Alan W. Irwin" <irwin(a)beluga.phys.uvic.ca> >>> wrote: >>>> >>>> The subject line pretty much says it all. Running MinGW/gcc under >>>> wineconsole for any simple test programme should demonstrate the issue >>>> for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large >>>> selection of 1.5.x and MinGW versions I have tried over the last year >>>> or so. >>>> >>>> I would be happy to supply more details if there is any difficulty >>>> replicating this reversion. >>>> >>>> Alan >>> >>> Please run a regression test and file a bug at http://bugs.winehq.org. >> >> No thank you. > > Why would anyone help you if you fail to do your homework? The shoe is on the other foot. I am trying to help Wine developers assuming they have an interest in fixing obvious problems in their code no matter how informally such problems are pointed out. This bug should be easy to replicate. Try to compile any C programme (e.g., a "Hello, world" programme) with MinGW-4.7.0 under wine-1.5.20 and that compiler segfaults. Do the same under wine-1.5.19, and there is no such problem. That's all that should be required to not only replicate the bug but also demonstrate the reversion. Meanwhile, I am happy to stick with 1.5.19 until some Wine developer takes responsibility for getting this regression fixed. If anybody tries such a test, and doesn't see the issue, then as I said before I am willing to supply more details. By the way, informal bug reports reported on mailing lists have been quite helpful to me in the past for my own software projects. I also have seen a number of projects spend an inordinate amount of time with bug triage rather than actually fixing the code. So I welcome informal bug reports for my own projects especially when an issue is easy to replicate. It appears you do not personally welcome such informal reports, but hopefully other wine developers are not so inflexible for obvious problems like this one is. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

Dec. 28, 2012

Re: wine-1.5.20 reversion compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole

by Frédéric Delanoy

On Mon, Dec 24, 2012 at 8:58 AM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > On 2012-12-23 21:25-0600 Austin English wrote: > >> On Dec 23, 2012 7:22 PM, "Alan W. Irwin" <irwin(a)beluga.phys.uvic.ca> >> wrote: >>> >>> The subject line pretty much says it all. Running MinGW/gcc under >>> wineconsole for any simple test programme should demonstrate the issue >>> for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large >>> selection of 1.5.x and MinGW versions I have tried over the last year >>> or so. >>> >>> I would be happy to supply more details if there is any difficulty >>> replicating this reversion. >>> >>> Alan >> >> Please run a regression test and file a bug at http://bugs.winehq.org. > > No thank you. Why would anyone help you if you fail to do your homework? Your bug description is rather vague and you can't expect people to start randomly testing apps until they (supposedly) find the bug you're talking about. Please provide a minimal "simple test program" If you want it fixed, failing to cooperate here won't help you much. Instead, create your test program, specify download links, and describe a minimal procedure to reproduce your bug (and add the appropriate keywords: download, patch, testcase, ...) http://wiki.winehq.org/BugReports and http://bugs.winehq.org/describekeywords.cgi can help here. For regressions, especially a rather recent one like you seem to suggest, there are more likely to be fixed quickly, especially if you perform the regression test yourself (reasons: you're in the best position to do it yourself; it can take some time developpers won't necessarily have: if they ran regression tests all day, when would they code???) See http://wiki.winehq.org/RegressionTesting > The last time I wrote a wine bug report (with a test case and a patch > to fix the problem no less), Which bug? > wine developers seemed content with the > fact that that bug had been reported. They did not actually fix the > problem until I made a special personal appeal to one of them more > than a year later. So eventually there was a happy ending there, but > the impression I got from that experience is that Wine bug reports for > even the most obvious issues like that one are pretty much a waste of > everyone's time unless and until a Wine developer takes > responsibility. Of course, in that case the bug reporting system is > worthwhile since it can make a permanent record of all the events > leading to a solution. If the bug was trivial to fix, why did you not send it yourself to wine-patches? There are a lot of bugs, and not many people who can fix those, so you can't expect *your* bug to be fixed in minutes. If you want to increase your chance for the bug to be fixed, you could wait less than a year, and e.g. restest if the bug still persists every couple of months (or better, after every wine release) and tell so on the bug report. No amount of complaining on this list will likely help... > In this case, I would like a Wine developer to take responsibility as > well for what I think is an obvious issue with 1.5.20 by verifying the > issue, and then taking any further development steps they want to take > concerning this issue. Or perhaps there will be an even more obvious > symptom of the problem with 1.5.20 that will lead to a solution > quicker than if someone follows the MinGW segfault symptom that I have > found. In other words, I am willing to help out Wine by reporting the > issue informally here, and let Wine developers make their best > judgement of what to do about the issue, but that is about it. Again, the bugzilla system is there to report bug, not this mailing list. Do you really expect someone to read your mail and create a bug from it??? > Sorry I have to be ruthless about this, but I do not want to get > involved in wine development or go through a bunch of Wine > bug-reporting hoops since I need to reserve my development efforts for > my own free software projects. If you don't want to be cooperative, why should we help you??? Creating a good bug report is not really "being involved in wine development" IMO. Mere users without any programming experience do it regularly. > > Alan Frédéric

Dec. 28, 2012

Re: [9/9] server: Add support for named pipe message mode.

by Daniel Jelinski

Hello, FWIW, Adam Martinson's named pipe series looks good to me. I tested it with MS SQL Server, which uses message mode pipes, and did not run into any problems. In current git I can't connect to server using named pipes, because as soon as SetNamedPipeHandleState returns false, client application aborts. (However, just changing SNPHS to return true is enough to get it working). I don't think patches 3 and 9 of this series can be split much more, except maybe for moving asserts into a separate file. Yes, reviewing them may cause headaches. The series is supposed to fix bugs 17273 (patch 8/9) and 17195 (patch 9/9). AFAICT the author is willing to make any adjustments necessary to get the patches merged. Patches 1-5 should not cause any problems if applied without the following. Patches 6-8 may cause regressions if applied without patch 9. Regards, Daniel

Dec. 27, 2012

Re: netstat: Initial implementation

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > + __ms_va_start(parms, format); > + len = vsprintfW(output_bufW, format, parms); > + __ms_va_end(parms); You can't mix vsprintfW and ms_va_list. -- Alexandre Julliard julliard(a)winehq.org

Dec. 27, 2012

Re: [2/2] windowscodecs: Implement ComponentFactory_CreateBitmapFromMemory.

by Vincent Povirk

Looks like I won't be around when this finishes, but I sent a test to testbot: https://testbot.winehq.org/JobDetails.pl?Key=23638 This should succeed if your implementation is correct (data is referenced, not copied).

Dec. 27, 2012

Re: [2/2] windowscodecs: Implement ComponentFactory_CreateBitmapFromMemory.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > I'm pretty sure CreateBitmapFromMemory copies the data rather than > referencing existing data. How do you know that? In any case adding a test case and support for that behaviour should be pretty trivial once this patch is accepted. -- Dmitry.

Dec. 27, 2012

Re: [2/2] windowscodecs: Implement ComponentFactory_CreateBitmapFromMemory.

by Vincent Povirk

>> I'm pretty sure CreateBitmapFromMemory copies the data rather than >> referencing existing data. > > How do you know that? In any case adding a test case and support for that > behaviour should be pretty trivial once this patch is accepted. I believe it was this stack overflow question that first tipped me off: http://stackoverflow.com/questions/11263099/render-direct2d-into-existing-m… There's also a comment on the documentation that suggests it does a copy: http://msdn.microsoft.com/en-us/library/ee690291%28v=vs.85%29.aspx Note that this was all before I did any real work with IWICBitmap. I think I tested this when I first implemented IWICBimap, to decide whether the ability to reference existing data would be needed at all, but if so I no longer have that test case. It should be trivial to add to your test. So, this is trivial to test and would mean that the features your patch would add are no longer needed (except possibly the ability to supply a stride for the new bitmap - but I would test that as well, as it seems very strange to me that WIC would copy the bits without removing the gaps). Potentially, your whole patch might have to be reverted in favor of copying image data in CreateBitmapFromMemory. I think it's better to skip adding new functionality than add it and remove it later.

Dec. 27, 2012

Re: netstat: Initial implementation

by André Hentschel

Am 27.12.2012 12:24, schrieb Alexandre Julliard: > André Hentschel <nerv(a)dawncrow.de> writes: > >> +STRINGTABLE >> +{ >> + IDS_TCP_UNKNOWN, "???" >> + IDS_TCP_CLOSED, "CLOSED" >> + IDS_TCP_LISTENING, "LISTENING" >> + IDS_TCP_SYN_SENT, "SYN_SENT" >> + IDS_TCP_SYN_RCVD, "SYN_RCVD" >> + IDS_TCP_ESTABLISHED, "ESTABLISHED" >> + IDS_TCP_FIN_WAIT1, "FIN_WAIT1" >> + IDS_TCP_FIN_WAIT2, "FIN_WAIT2" >> + IDS_TCP_CLOSE_WAIT, "CLOSE_WAIT" >> + IDS_TCP_CLOSING, "CLOSING" >> + IDS_TCP_LAST_ACK, "LAST_ACK" >> + IDS_TCP_TIME_WAIT, "TIME_WAIT" >> + IDS_TCP_DELETE_TCB, "DELETE_TCB" > > It's not useful to put these in resources, we don't want to have to > translate them. > They get translated on Windows. e.g. "ESTABLISHED" is "HERGESTELLT" in german. -- Best Regards, André Hentschel

Dec. 27, 2012

Re: [2/2] windowscodecs: Implement ComponentFactory_CreateBitmapFromMemory.

by Vincent Povirk

I'm pretty sure CreateBitmapFromMemory copies the data rather than referencing existing data. On Thu, Dec 27, 2012 at 3:29 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > --- > dlls/windowscodecs/bitmap.c | 31 +++++++++++++++++++++---------- > dlls/windowscodecs/imgfactory.c | 18 +++++++++++------- > dlls/windowscodecs/tests/bitmap.c | 5 ----- > dlls/windowscodecs/wincodecs_private.h | 1 + > 4 files changed, 33 insertions(+), 22 deletions(-) > > diff --git a/dlls/windowscodecs/bitmap.c b/dlls/windowscodecs/bitmap.c > index 520fdef..4d48651 100644 > --- a/dlls/windowscodecs/bitmap.c > +++ b/dlls/windowscodecs/bitmap.c > @@ -40,6 +40,7 @@ typedef struct BitmapImpl { > int palette_set; > LONG lock; /* 0 if not locked, -1 if locked for writing, count if locked for reading */ > BYTE *data; > + BOOL owndata; > UINT width, height; > UINT stride; > UINT bpp; > @@ -260,7 +261,8 @@ static ULONG WINAPI BitmapImpl_Release(IWICBitmap *iface) > if (This->palette) IWICPalette_Release(This->palette); > This->cs.DebugInfo->Spare[0] = 0; > DeleteCriticalSection(&This->cs); > - HeapFree(GetProcessHeap(), 0, This->data); > + if (This->owndata) > + HeapFree(GetProcessHeap(), 0, This->data); > HeapFree(GetProcessHeap(), 0, This); > } > > @@ -447,28 +449,37 @@ static const IWICBitmapVtbl BitmapImpl_Vtbl = { > }; > > HRESULT BitmapImpl_Create(UINT uiWidth, UINT uiHeight, > + UINT stride, UINT datasize, BYTE *data, > REFWICPixelFormatGUID pixelFormat, WICBitmapCreateCacheOption option, > IWICBitmap **ppIBitmap) > { > HRESULT hr; > BitmapImpl *This; > - UINT bpp, stride, datasize; > - BYTE *data; > + UINT bpp; > > hr = get_pixelformat_bpp(pixelFormat, &bpp); > if (FAILED(hr)) return hr; > > - stride = (((bpp*uiWidth)+31)/32)*4; > - datasize = stride * uiHeight; > + if (!stride) stride = (((bpp*uiWidth)+31)/32)*4; > + if (!datasize) datasize = stride * uiHeight; > + > + if (datasize < stride * uiHeight) return WINCODEC_ERR_INSUFFICIENTBUFFER; > + if (stride < (((bpp*uiWidth)+31)/32)*4) return E_INVALIDARG; > > This = HeapAlloc(GetProcessHeap(), 0, sizeof(BitmapImpl)); > - data = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, datasize); > - if (!This || !data) > + if (!This) return E_OUTOFMEMORY; > + if (!data) > { > - HeapFree(GetProcessHeap(), 0, This); > - HeapFree(GetProcessHeap(), 0, data); > - return E_OUTOFMEMORY; > + data = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, datasize); > + if (!data) > + { > + HeapFree(GetProcessHeap(), 0, This); > + return E_OUTOFMEMORY; > + } > + This->owndata = TRUE; > } > + else > + This->owndata = FALSE; > > This->IWICBitmap_iface.lpVtbl = &BitmapImpl_Vtbl; > This->ref = 1; > diff --git a/dlls/windowscodecs/imgfactory.c b/dlls/windowscodecs/imgfactory.c > index 54b390b..1d05ef5 100644 > --- a/dlls/windowscodecs/imgfactory.c > +++ b/dlls/windowscodecs/imgfactory.c > @@ -1,5 +1,6 @@ > /* > * Copyright 2009 Vincent Povirk for CodeWeavers > + * Copyright 2012 Dmitry Timoshkov > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -459,7 +460,7 @@ static HRESULT WINAPI ComponentFactory_CreateBitmap(IWICComponentFactory *iface, > { > TRACE("(%p,%u,%u,%s,%u,%p)\n", iface, uiWidth, uiHeight, > debugstr_guid(pixelFormat), option, ppIBitmap); > - return BitmapImpl_Create(uiWidth, uiHeight, pixelFormat, option, ppIBitmap); > + return BitmapImpl_Create(uiWidth, uiHeight, 0, 0, NULL, pixelFormat, option, ppIBitmap); > } > > static HRESULT WINAPI ComponentFactory_CreateBitmapFromSource(IWICComponentFactory *iface, > @@ -506,7 +507,7 @@ static HRESULT WINAPI ComponentFactory_CreateBitmapFromSource(IWICComponentFacto > } > > if (SUCCEEDED(hr)) > - hr = BitmapImpl_Create(width, height, &pixelformat, option, &result); > + hr = BitmapImpl_Create(width, height, 0, 0, NULL, &pixelformat, option, &result); > > if (SUCCEEDED(hr)) > { > @@ -576,12 +577,15 @@ static HRESULT WINAPI ComponentFactory_CreateBitmapFromSourceRect(IWICComponentF > } > > static HRESULT WINAPI ComponentFactory_CreateBitmapFromMemory(IWICComponentFactory *iface, > - UINT uiWidth, UINT uiHeight, REFWICPixelFormatGUID pixelFormat, UINT cbStride, > - UINT cbBufferSize, BYTE *pbBuffer, IWICBitmap **ppIBitmap) > + UINT width, UINT height, REFWICPixelFormatGUID format, UINT stride, > + UINT size, BYTE *buffer, IWICBitmap **bitmap) > { > - FIXME("(%p,%u,%u,%s,%u,%u,%p,%p): stub\n", iface, uiWidth, uiHeight, > - debugstr_guid(pixelFormat), cbStride, cbBufferSize, pbBuffer, ppIBitmap); > - return E_NOTIMPL; > + TRACE("(%p,%u,%u,%s,%u,%u,%p,%p\n", iface, width, height, > + debugstr_guid(format), stride, size, buffer, bitmap); > + > + if (!stride || !size || !buffer || !bitmap) return E_INVALIDARG; > + > + return BitmapImpl_Create(width, height, stride, size, buffer, format, WICBitmapCacheOnLoad, bitmap); > } > > static HRESULT WINAPI ComponentFactory_CreateBitmapFromHBITMAP(IWICComponentFactory *iface, > diff --git a/dlls/windowscodecs/tests/bitmap.c b/dlls/windowscodecs/tests/bitmap.c > index cec714b..3cdbffd 100644 > --- a/dlls/windowscodecs/tests/bitmap.c > +++ b/dlls/windowscodecs/tests/bitmap.c > @@ -436,27 +436,22 @@ static void test_CreateBitmapFromMemory(void) > > hr = IWICImagingFactory_CreateBitmapFromMemory(factory, 3, 3, &GUID_WICPixelFormat24bppBGR, > 0, 0, NULL, &bitmap); > -todo_wine > ok(hr == E_INVALIDARG, "expected E_INVALIDARG, got %#x\n", hr); > > hr = IWICImagingFactory_CreateBitmapFromMemory(factory, 3, 3, &GUID_WICPixelFormat24bppBGR, > 0, sizeof(data3x3), data3x3, &bitmap); > -todo_wine > ok(hr == E_INVALIDARG, "expected E_INVALIDARG, got %#x\n", hr); > > hr = IWICImagingFactory_CreateBitmapFromMemory(factory, 3, 3, &GUID_WICPixelFormat24bppBGR, > 6, sizeof(data3x3), data3x3, &bitmap); > -todo_wine > ok(hr == E_INVALIDARG, "expected E_INVALIDARG, got %#x\n", hr); > > hr = IWICImagingFactory_CreateBitmapFromMemory(factory, 3, 3, &GUID_WICPixelFormat24bppBGR, > 12, sizeof(data3x3), data3x3, &bitmap); > -todo_wine > ok(hr == WINCODEC_ERR_INSUFFICIENTBUFFER, "expected WINCODEC_ERR_INSUFFICIENTBUFFER, got %#x\n", hr); > > hr = IWICImagingFactory_CreateBitmapFromMemory(factory, 3, 3, &GUID_WICPixelFormat24bppBGR, > 9, sizeof(data3x3) - 1, data3x3, &bitmap); > -todo_wine > ok(hr == WINCODEC_ERR_INSUFFICIENTBUFFER, "expected WINCODEC_ERR_INSUFFICIENTBUFFER, got %#x\n", hr); > > hr = IWICImagingFactory_CreateBitmapFromMemory(factory, 3, 3, &GUID_WICPixelFormat24bppBGR, > diff --git a/dlls/windowscodecs/wincodecs_private.h b/dlls/windowscodecs/wincodecs_private.h > index 6857176..508bb2c 100644 > --- a/dlls/windowscodecs/wincodecs_private.h > +++ b/dlls/windowscodecs/wincodecs_private.h > @@ -45,6 +45,7 @@ extern HRESULT IcnsEncoder_CreateInstance(IUnknown *pUnkOuter, REFIID iid, void* > extern HRESULT TgaDecoder_CreateInstance(IUnknown *pUnkOuter, REFIID iid, void** ppv) DECLSPEC_HIDDEN; > > extern HRESULT BitmapImpl_Create(UINT uiWidth, UINT uiHeight, > + UINT stride, UINT datasize, BYTE *data, > REFWICPixelFormatGUID pixelFormat, WICBitmapCreateCacheOption option, > IWICBitmap **ppIBitmap) DECLSPEC_HIDDEN; > extern HRESULT BitmapScaler_Create(IWICBitmapScaler **scaler) DECLSPEC_HIDDEN; > -- > 1.8.0.2 > > >

Dec. 27, 2012