wine-devel December 2007

wine-devel@winehq.org

139 participants
264 discussions

Nifty new valgrind report script. New error in oleaut32. Call for volunteer(s).
by Dan Kegel 07 Dec '07

07 Dec '07

I finally got tired of doing "history | grep diff" etc, and partially automated the daily valgrind run; the resulting script is at http://kegel.com/wine/valgrind/valgrind-daily.sh The results are now in directories named like http://kegel.com/wine/valgrind/logs-2007-12-06/ A summary of the new problems compared to last run are in files named like http://kegel.com/wine/valgrind/logs-2007-12-06-summary.txt And next to each individual result, there is a diff with the previous run, e.g. http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat.txt http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat-diff.t… To look at what changed since yesterday, start by looking at the day's summary file. In it, there's one line per test, followed by the changes in that test's results, if any. Lines that start with + indicate new problems (boo); lines that start with - indicate old problems that are now gone (yay!) Nearby lines that are identical except for one starting with + and one starting with - indicate a problem that moved, so ignore those. For example, in today's summary, http://kegel.com/wine/valgrind/logs-2007-12-06-summary.txt the first test with changes is in hlink: diff -u logs-2007-12-05/vg-hlink_hlink.txt logs-2007-12-06/vg-hlink_hlink.txt - Syscall param write(buf) points to uninitialised byte(s) That means the hlink test has one fewer error. Yay! The next test with changes is diff -u logs-2007-12-05/vg-ole32_moniker.txt logs-2007-12-06/vg-ole32_moniker.txt + Syscall param write(buf) points to uninitialised byte(s) - Syscall param write(buf) points to uninitialised byte(s) - Conditional jump or move depends on uninitialised value(s) The 'Syscall' error just moved, so that's not really a change. The 'Conditional' error went away, yay! The next test with changes is diff -u logs-2007-12-05/vg-oleaut32_varformat.txt logs-2007-12-06/vg-oleaut32_varformat.txt + Invalid read of size 2 That's a + with no matching -, so it's a new error, boo! Let's see if it's a real error, or just crap in the log. The first thing to check is the diff of that test's results with the last run: http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat-diff.t… It shows a fairly convincing new error: + Invalid read of size 2 + at VarFormatFromTokens (varformat.c:1888) + by VarFormat (varformat.c:2096) + by func_varformat (varformat.c:317) + by run_test (test.h:387) + by main (test.h:436) + Address 0x7F00AB01 is 15 bytes before a block of size 8 alloc'd + at RtlAllocateHeap (heap.c:1225) + by SysAllocStringByteLen (oleaut.c:357) + by VariantCopy (variant.c:722) + by VariantChangeTypeEx (variant.c:992) + by VarFormatFromTokens (varformat.c:1884) + by VarFormat (varformat.c:2096) + by func_varformat (varformat.c:317) + by run_test (test.h:387) + by main (test.h:436) Now, sometimes tests are flaky, and errors just happen to come and go, so this doesn't mean for sure it's a new error. But looking back a few days, I don't see it before. So it's probably a new error. Let's see, who's been submitting changes to oleaut32 lately? Only change in git since the last run seems to be http://www.winehq.org/pipermail/wine-cvs/2007-December/038491.html It's not clear how that patch could have caused the error offhand, but it's worth emailing the author and asking him to check, so I've cc'd him. And that's the only new error in the whole run. It's worth watching for new errors and alerting the authors, since the change is fresh in their mind, they'll probably be able to fix it quickly. Egg in the face is a dish best served warm. I'll try to keep running this script daily, but it'd be nice if somebody else took over (and possibly even increased the automation; I still have to do git pull, run the script, and upload by hand.) It doesn't help that valgrind only works well on some machines, but hey, what's life without challenges. - Dan

1 0

Re: gdi32: Update fontsubstitutes and add ms shell dlg 2
by Huw Davies 07 Dec '07

07 Dec '07

On Fri, Dec 07, 2007 at 01:20:59PM +0100, Maarten Lankhorst wrote: > --- > dlls/gdi32/freetype.c | 34 ++++++++++++++++++---------------- > 1 files changed, 18 insertions(+), 16 deletions(-) > diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c > index e9fb663..1542e29 100644 > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -1884,83 +1884,83 @@ static const struct nls_update_font_list > const char *oem, *fixed, *system; > const char *courier, *serif, *small, *sserif; > /* these are for font substitute */ > - const char *shelldlg, *tmsrmn; > + const char *shelldlg, *shelldlg2, *tmsrmn; > } nls_update_font_list[] = > { > /* Latin 1 (United States) */ > { 1252, 437, "vgaoem.fon", "vgafix.fon", "vgasys.fon", > "coure.fon", "serife.fon", "smalle.fon", "sserife.fon", > - "Tahoma","Times New Roman", > + "MS Sans Serif", "Tahoma","Times New Roman", > }, I'm fairly sure we don't want to map MS Shell Dlg to MS Sans Serif. Which version of Windows has this mapping? Some map it to Microsoft Sans Serif, but that's a completely different font... Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: [2/2] msxml3: Register Missing Components
by Huw Davies 07 Dec '07

07 Dec '07

On Fri, Dec 07, 2007 at 02:07:44PM +1100, Alistair Leslie-Hughes wrote: > diff --git a/dlls/msxml3/regsvr.c b/dlls/msxml3/regsvr.c > index 9a0d938..1beed5b 100644 > --- a/dlls/msxml3/regsvr.c > +++ b/dlls/msxml3/regsvr.c > @@ -465,13 +465,13 @@ static LONG register_key_defvalueA( > */ > static struct regsvr_coclass const coclass_list[] = { > { &CLSID_DOMDocument, > - "XML DOM Document", > - NULL, > - "msxml3.dll", > - "Both", > - "Microsoft.XMLDOM", > - "1.0" > - }, > + "XML DOM Document", > + NULL, > + "msxml3.dll", > + "Both", > + "Microsoft.XMLDOM", > + "1.0" > + }, There are a lot of white-space changes in this patch. Please re-submit without them. Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

1 0

d3d fill caps oddity
by Christoph Frick 07 Dec '07

07 Dec '07

Hi wined3d devs, i get this message on my notebook (Quadro 570m): fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers does anyone want some traces or other infos? or is this a problem most likely going away with the next nvidia driver update? -- cu

2 1

Re: [1/2] msxml3: Implement IPersistStream
by Robert Shearman 07 Dec '07

07 Dec '07

Alistair Leslie-Hughes wrote: > + hr = CreateStreamOnHGlobal(NULL, TRUE, &This->stream); > + if (FAILED(hr)) > + return hr You need to free This->stream somewhere. -- Rob Shearman

1 0

Re: [5/5] WineD3D: Use the disabled opengl extension string
by H. Verbeet 07 Dec '07

07 Dec '07

The clearest way to do this would probably be to simply do the disabling in a separate loop over the disabled extensions string, similarly to how we detect the extensions.

2 1

wine 0.9.5 IO completion port questions
by Marius Slyzius 07 Dec '07

07 Dec '07

Hello all. I am trying to run ScimoreDB database which uses fibers, non-blocked IO for sockets and files, and completion port. It did started ok under 0.9.5 and seems it is working!!!:), so I would like to verify few things about async IO with completion ports before recompiling it with winelib. 1) will write/read file/socket with completion port is true asynchronous operation. I am asking because every time write/read operation returns true, and never IO pending error. 2) possible bug: the server sends 1500 bytes with WsaSend ( with 2 WSABUFFER ) and the client receive only 1452 bytes and calls WsaRecv again. Also on the server, the completion port receive event that transferred 1452 bytes. However, the last 8 bytes are never sends nor completion port event arrives. Is it perhaps something to do with the VMWare tool where I run Ubuntu 7.10? Please, send me an info also to my mail: marius(a)scimore.com , because I might miss the answer here. Thank you! Marius Slyzius Scimore UAB (+45) 40862122

4 3

replying to wine-devel?
by King InuYasha 07 Dec '07

07 Dec '07

I have noticed some unusual behavior in the wine-devel mailing list compared to others (e.g. fedora's, etc.). Wine's wine-devel mailing list does not automatically set the reply to wine-devel(a)winehq.org. Why is that? If other mailing lists do so, how come Wine's doesn't? Personally, I find myself making a mistake sometimes and not adding in the wine-devel part because I am used to seeing it automatically set. If I remember how emails are set up, isn't there a hidden field called reply-to? AFAICT, other mailing lists either override or rewrite this field and replace it with the email address of the mailing list.

6 8

Re: [5/5] WineD3D: Use the disabled opengl extension string
by Chris Robinson 07 Dec '07

07 Dec '07

On Thursday 06 December 2007 02:05:52 pm Stefan Dösinger wrote: > + if(wined3d_settings.disabled_extensions && > + strstr(wined3d_settings.disabled_extensions, > ThisExtn)) { You need to be careful with this. I read somewhere that using strstr to check for an opengl extension in an extension list is discourage because it can find false positives. Especially in this case, if you have, say: wined3d_settings.disabled_extensions = "GL_NV_texture_shader3 GL_NV_vertex_program2_option GL_NV_vertex_program3" Then if you check for "GL_NV_texture_shader", "GL_NV_vertex_program2", or "GL_NV_vertex_program", they'll all show up as being disabled, when they're not. Which is a double problem because "GL_NV_vertex_program1_1" would still be enabled, which requires "GL_NV_vertex_program". AFAIK, the proper way to check for OpenGL extensions in a space-delimitted list is like this: const char *ptr = strstr(wined3d_settings.disabled_extensions, ThisExtn); if(ptr) { if(ptr == wined3d_settings.disabled_extensions || isspace(ptr[-1])) { int len = strlen(ThisExtn); if(!ptr[len] || isspace(ptr[len])) { /* is disabled */ } } }

1 0

Re: d3dx8 [2/2]: add basic functions for MatrixStack
by Stefan Dösinger 06 Dec '07

06 Dec '07

Am Mittwoch, 5. Dezember 2007 18:13:30 schrieb David.Adam(a)math.cnrs.fr: > This is my first attempt with ICOM objects. So, all the advices are > welcome. A few suggestions: +HRESULT WINAPI ID3DXMatrixStackImpl_QueryInterface(ID3DXMatrixStack *iface, REFIID riid, void **ppvObject) + ... + IClassFactory_AddRef(iface); It is better to use ID3DXMatrixStack_AddRef(iface) here. It is essentially the same, but it looks more consistent The AddRef() and Release() methods should have a TRACE which write either the new or old refcount, otherwise tracking refcounting bugs is hell.

3 3

← Newer
1
...
20
21
22
23
24
25
26
27
Older →

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-devel December 2007