February 2008 - Wine-Devel - list.winehq.org

Re: Regesstion Tests

by Paul Vriens

Alistair Leslie-Hughes wrote: > Hi, > If I have Msxml3 with SP7 installed all the msxml tests pass without > issue, but if I have Msxml3 SP3 installed, some fail. > > Should I improve the tests so that they can handle both cases? > > Best Regards > Alistair Leslie-Hughes > > > > > Hi, The general rule is to have the tests pass on all versions of OS/applications/dll's. This has to be done, if possible, by checking behavior instead of retrieving version information. -- Cheers, Paul.

Feb. 12, 2008

Regular bugzilla hygeine

by Dan Kegel

When we do a release, all the bugs in RESOLVED FIXED state can be closed (since they were only waiting on a release to be closed). We haven't been doing that, and as a result, lots and lots of bugs stacked up in RESOLVED FIXED state. But I don't see any reason we shouldn't start doing it, so I'm about to do it in honor of the 0.9.55 release. (I think I've figured out how to avoid changing any bugs flipped into that state since the 0.9.55 release, let's see if I get it right. Next time I'll do it right when Alexandre releases.) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Feb. 12, 2008

Re: comctl32: Fixed listview bug, when client sends bogus SETITEMSTATE request

by Dimi Paun

On Tue, 2008-02-12 at 03:28 +0100, Peter Dons Tychsen wrote: > Fixed listview bug, when client sends bogus SETITEMSTATE request, > requesting all items to be focused. Looks good, tnx! -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Feb. 12, 2008

Regesstion Tests

by Alistair Leslie-Hughes

Hi, If I have Msxml3 with SP7 installed all the msxml tests pass without issue, but if I have Msxml3 SP3 installed, some fail. Should I improve the tests so that they can handle both cases? Best Regards Alistair Leslie-Hughes

Feb. 12, 2008

gecko valgrind errors show up better now

by Dan Kegel

The new version of valgrind shows better stack dumps for gecko valgrind errors. For instance, Invalid read of size 4 at (within 0.1.0/wine_gecko/components/xppref32.dll) by (within 0.1.0/wine_gecko/components/xppref32.dll) by (within 0.1.0/wine_gecko/components/xppref32.dll) by (within 0.1.0/wine_gecko/components/xppref32.dll) by (within 0.1.0/wine_gecko/components/xppref32.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by load_gecko (nsembed.c:396) by NSContainer_Create (nsembed.c:1574) by HTMLDocument_Create (htmldoc.c:1232) by ClassFactory_CreateInstance (main.c:206) by CoCreateInstance (compobj.c:2411) by report_data (binding.c:444) by report_data_proc (binding.c:1262) Address 0x7f22e1e0 is not stack'd, malloc'd or (recently) free'd Invalid read of size 4 at (within 0.1.0/wine_gecko/components/rdf.dll) by (within 0.1.0/wine_gecko/components/rdf.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/profile.dll) by (within 0.1.0/wine_gecko/components/profile.dll) by load_gecko (nsembed.c:338) by NSContainer_Create (nsembed.c:1574) by HTMLDocument_Create (htmldoc.c:1232) by ClassFactory_CreateInstance (main.c:206) by CoCreateInstance (compobj.c:2411) by report_data (binding.c:444) by report_data_proc (binding.c:1262) by notif_wnd_proc (binding.c:184) Address 0x7f22e108 is not stack'd, malloc'd or (recently) free'd Conditional jump or move depends on uninitialised value(s) at (within 0.1.0/wine_gecko/components/necko.dll) by nsURI_QueryInterface (nsio.c:1181) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by nsIOService_NewChannelFromURI (nsio.c:2111) by (within 0.1.0/wine_gecko/components/rdf.dll) by (within 0.1.0/wine_gecko/components/rdf.dll) by (within 0.1.0/wine_gecko/components/rdf.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/profile.dll) by (within 0.1.0/wine_gecko/components/profile.dll) by load_gecko (nsembed.c:338) Invalid read of size 4 at (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/xpc3250.dll) by (within 0.1.0/wine_gecko/components/xpc3250.dll) by (within 0.1.0/wine_gecko/components/xpc3250.dll) by (within 0.1.0/wine_gecko/components/xpc3250.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/profile.dll) by load_gecko (nsembed.c:338) by NSContainer_Create (nsembed.c:1574) by HTMLDocument_Create (htmldoc.c:1232) by ClassFactory_CreateInstance (main.c:206) by CoCreateInstance (compobj.c:2411) by report_data (binding.c:444) by report_data_proc (binding.c:1262) by notif_wnd_proc (binding.c:184) by (within /home/dank/wine-git/dlls/user32/user32.dll.so) Address 0x7f22d1a8 is not stack'd, malloc'd or (recently) free'd etc., etc. Jacek, if you can give me a debug build of gecko, I can probably give you even better info. Interested? - Dan

Feb. 12, 2008

dbghelp/dwarf.c: new valgrind warnings?

by Dan Kegel

I'm now seeing some new valgrind warnings when wine is doing stack dumps after crashes: + Conditional jump or move depends on uninitialised value(s) + at dwarf2_load_one_entry (dwarf.c:983) + by dwarf2_lookup_type (dwarf.c:858) + by dwarf2_load_one_entry (dwarf.c:1020) + by dwarf2_parse (dwarf.c:2060) + by elf_load_debug_info (elf_module.c:1085) + by module_get_debug (module.c:303) + by SymFromAddr (symbol.c:1071) + by stack_get_current_symbol (stack.c:143) + by display_print (display.c:174) + by wait_exception (tgt_active.c:178) + by dbg_active_auto (tgt_active.c:951) + by main (winedbg.c:544) I don't know when this started, but maybe it's related to recent changes by Eric Pouech? - Dan

Feb. 12, 2008

Re: Resend patch from Norbert

by Stefan Dösinger

Am Montag, 11. Februar 2008 19:39:27 schrieb Rico Schüller: > Vitaliy Margolen wrote: > > Rico Schüller wrote: > >> Hi, > >> > >> I only resend a patch because it isn't in the todays git and the author > >> didn't answer for a while. > >> > >> Cheers > >> Rico > >> > >> > >> ------------------------------------------------------------------------ > >> > >> > >> - memcpy(pRect, &This->updateStateBlock->scissorRect, sizeof(pRect)); > >> + memcpy(pRect, &This->updateStateBlock->scissorRect, sizeof(RECT)); > > > > To avoid such problems in the future one should use something like: > > > > *pRect = This->updateStateBlock->scissorRect; > > > > Doing a quick search through wined3d I've found number of places with > > memcpy instead of simple assignment of one struct to another struct. This > > is a good janitorial task to get rid of memcpy where simple assignment > > will work. > > > > Vitaliy. > > Is this the reason why this patch isn't excepted? Or is there any other > reason? I think because the suggested assignment is prefered over the memcpy that the patch uses

Feb. 11, 2008

Re: Resend patch from Norbert

by Rico Schüller

Vitaliy Margolen wrote: > Rico Schüller wrote: >> Hi, >> >> I only resend a patch because it isn't in the todays git and the author >> didn't answer for a while. >> >> Cheers >> Rico >> >> >> ------------------------------------------------------------------------ >> >> >> - memcpy(pRect, &This->updateStateBlock->scissorRect, sizeof(pRect)); >> + memcpy(pRect, &This->updateStateBlock->scissorRect, sizeof(RECT)); > > To avoid such problems in the future one should use something like: > > *pRect = This->updateStateBlock->scissorRect; > > Doing a quick search through wined3d I've found number of places with memcpy > instead of simple assignment of one struct to another struct. This is a good > janitorial task to get rid of memcpy where simple assignment will work. > > Vitaliy. > > > Is this the reason why this patch isn't excepted? Or is there any other reason? Cheers Rico

Feb. 11, 2008

Re: IStream interface for domdoc and terminate call

by Kornél Pál

Also note you should test the behavior when call QueryInterface for IStream multiple times whether a new wrapper or the same wrapper is returned and whether the tree is cleared on QueryInterface. And I forgot to mention that calling Release on the IStream interface is the correct way of disposing the interface so that call may have effect on the object as well. Kornél ----- Original Message ----- From: "Kornél Pál" <kornelpal(a)gmail.com> To: "Josef Reidinger" <josef.reidinger(a)gmail.com>; <wine-devel(a)winehq.org> Sent: Monday, February 11, 2008 1:15 PM Subject: Re: IStream interface for domdoc and terminate call > OK, sorry I didn't realized that you try to modify the Wine > implementation. > > I think that delaying pasing for the fist time you call a method of the > DOMDocument object would be a good solution. This way you will not perform > any unnecessary parings. > > I don't know the exact details of MS implementations so you should check > when and how are parsing errors reported and when is the parsed document > available when you write the DOMDocument throug it's IStream interface and > you should dealy parsing to the latest possible time. > > Kornél > > ----- Original Message ----- > From: "Josef Reidinger" <josef.reidinger(a)gmail.com> > To: "Kornél Pál" <kornelpal(a)gmail.com> > Sent: Monday, February 11, 2008 12:58 PM > Subject: Re: IStream interface for domdoc and terminate call > > >> Hi >> I mean using call IStream_write like it is describe in bug #4811. >> >> Kornél Pál napsal(a): >>> Hi, >>> >>> If you mean passing an IStream interface to DOMDocument.save method: >>> As far as I know save method is synchronous (if I'm wrong you still can >>> set the async property to FALSE). So when the save method returns you >>> know that the entire document has been passed to the IStream. >>> >>> If you want to do something else please be more specific. >>> >>> Kornél >>> >>> ----- Original Message ----- From: "Josef Reidinger" >>> <josef.reidinger(a)gmail.com> >>> To: <wine-devel(a)winehq.org> >>> Sent: Monday, February 11, 2008 11:55 AM >>> Subject: IStream interface for domdoc and terminate call >>> >>> >>>> Hi, I try make IStream write interface for domdoc (msxml3). Problem is >>>> that microsoft doesn't have terminate string for write call and libxml >>>> have proble with it (more at >>>> http://mail.gnome.org/archives/xml/2008-February/msg00052.html ). Does >>>> anyone has any idea how solve it? (test in each dom call if is some >>>> nonparsed characters and force parsing looks very ugly). >>>> JR >>>> >>>> >>> >> >

Feb. 11, 2008

Re: IStream interface for domdoc and terminate call

by Kornél Pál

OK, sorry I didn't realized that you try to modify the Wine implementation. I think that delaying pasing for the fist time you call a method of the DOMDocument object would be a good solution. This way you will not perform any unnecessary parings. I don't know the exact details of MS implementations so you should check when and how are parsing errors reported and when is the parsed document available when you write the DOMDocument throug it's IStream interface and you should dealy parsing to the latest possible time. Kornél ----- Original Message ----- From: "Josef Reidinger" <josef.reidinger(a)gmail.com> To: "Kornél Pál" <kornelpal(a)gmail.com> Sent: Monday, February 11, 2008 12:58 PM Subject: Re: IStream interface for domdoc and terminate call > Hi > I mean using call IStream_write like it is describe in bug #4811. > > Kornél Pál napsal(a): >> Hi, >> >> If you mean passing an IStream interface to DOMDocument.save method: >> As far as I know save method is synchronous (if I'm wrong you still can >> set the async property to FALSE). So when the save method returns you >> know that the entire document has been passed to the IStream. >> >> If you want to do something else please be more specific. >> >> Kornél >> >> ----- Original Message ----- From: "Josef Reidinger" >> <josef.reidinger(a)gmail.com> >> To: <wine-devel(a)winehq.org> >> Sent: Monday, February 11, 2008 11:55 AM >> Subject: IStream interface for domdoc and terminate call >> >> >>> Hi, I try make IStream write interface for domdoc (msxml3). Problem is >>> that microsoft doesn't have terminate string for write call and libxml >>> have proble with it (more at >>> http://mail.gnome.org/archives/xml/2008-February/msg00052.html ). Does >>> anyone has any idea how solve it? (test in each dom call if is some >>> nonparsed characters and force parsing looks very ugly). >>> JR >>> >>> >> >

Feb. 11, 2008