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

valgrind bot back online

by Dan Kegel

The valgrind bot seems to have locked up soon after I left for vacation, but it's back up. Today's results: http://kegel.com/wine/valgrind/logs/2009-12-31-09.07/ Stats: 1 Invalid free/ delete / delete[] 1 Use of uninitialised value of size 4 2 Invalid write of size 4 2 Source and destination overlap in memcpy 3 Syscall param writev 6 Invalid read of size 2 8 Invalid write of size 1 12 Invalid read of size 4 49 Conditional jump or move depends on uninitialised value 598 XXX bytes in XXX blocks are definitely lost total: 682 The total on Dec 18th was 807. Nice progress!

Dec. 31, 2009

Re: va_list breakage introduced today

by Gerald Pfeifer

On Thu, 31 Dec 2009, Reece Dunn wrote: > Have you tried this patch?: > http://www.winehq.org/pipermail/wine-patches/2009-December/083364.html > (This is in the latest git -- Yep, that works. Thanks! Gerald

Dec. 31, 2009

Re: va_list breakage introduced today

by Reece Dunn

2009/12/30 Gerald Pfeifer <gerald(a)pfeifer.com>: > I believe the following patch > > commit 8268ed978389662c7b43212e008037cae3ce900e > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Dec 28 22:19:31 2009 +0100 > > kernel32: Do not include 16-bit headers in 32-bit files. > > is causing > > gmake[2]: Entering directory `/usr/test/Wine/dlls/kernel32' /files/pfeifer/gcc/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wtype-limits -Wpointer-arith -I/usr/local/include -g -O2 -o module.o module.c > In file included from module.c:36:0: > ../../include/winbase.h:1560:84: error: expected declaration specifiers or '...' before 'va_list' > ../../include/winbase.h:1561:85: error: expected declaration specifiers or '...' before 'va_list' > In file included from module.c:37:0: > ../../include/winternl.h:2223:81: error: expected declaration specifiers or '...' before 'va_list' > ../../include/winternl.h:2389:58: error: expected declaration specifiers or '...' before 'va_list' > ../../include/winternl.h:2390:75: error: expected declaration specifiers or '...' before 'va_list' Have you tried this patch?: http://www.winehq.org/pipermail/wine-patches/2009-December/083364.html (This is in the latest git -- http://source.winehq.org/git/wine.git/?a=commitdiff;h=4f60b6bf91f1bf797a37b…)

Dec. 31, 2009

Re: WineTestBot changes

by André Hentschel

Greg Geldorp schrieb: > I've completed phase 2 of the testbot: besides (32 and 64 bit) Windows executables you can now also submit patch files to the bot. The bot will apply the patch files to a clean git tree, cross-compile the test and run the test on Windows VMs. You'll also be able to download the cross-compiled test executable to test it on different Windows machines. > > Ge. > > > Great! Now we have a Wine-VM we should also change the batch to run the testsuite in Wine, too. -- Best Regards, André Hentschel

Dec. 31, 2009

Re: [PATCH 2/2] d3d10: Parse effect shaders as anonymous shaders.

by Henri Verbeet

2009/12/31 Rico Schüller <kgbricola(a)web.de>: > struct d3d10_effect_shader_variable *s; ... > + v->data = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct d3d10_effect_shader_variable)); ... > + s = v->data; I think this would be nicer: s = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*s)); ... v->data = s; That's mostly my fault for writing it like that in the first place, but we might as well fix that. > + default: > + ERR("This should not happen!\n"); > + break; You'll probably want to return E_FAIL here. > + struct d3d10_effect_variable *v = &e->anonymous_shaders[e->anonymous_shader_current]; > + struct d3d10_effect_type *t = &e->anonymous_shader_type[e->anonymous_shader_current]; ... > + hr = parse_fx10_anonymous_shader(o->pass->technique->effect, o->type); ... > + o->data = &o->pass->technique->effect->anonymous_shaders[o->pass->technique->effect->anonymous_shader_current-1]; If you create a structure for anonymous shaders, you can store that in a single array. You can then pass a pointer to that structure to parse_fx10_anonymous_shader(), and handle "anonymous_shader_current" in parse_fx10_object(). E.g.: struct d3d10_effect *effect = o->pass->technique->effect; struct d3d10_effect_anonymous_shader *shader = &effect->anonymous_shaders[effect->anonymous_shader_current]; hr = parse_fx10_anonymous_shader(effect, o->type, shader); if (FAILED(hr)) return hr; ++effect->anonymous_shader_current; o->data = shader; Note that you should also validate that "anonymous_shader_current" < "anonymous_shader_count". The count is supposed to be correct, but the .fx might lie about it, possibly on purpose.

Dec. 31, 2009

Re: [PATCH 1/2] d3d10: Add a function to initialize the null variables.

by Henri Verbeet

2009/12/31 Rico Schüller <kgbricola(a)web.de>: > +static struct d3d10_effect_variable null_local_buffer = {0}; > +static struct d3d10_effect_variable null_variable = {0}; > +static struct d3d10_effect_variable null_scalar_variable = {0}; > +static struct d3d10_effect_variable null_vector_variable = {0}; > +static struct d3d10_effect_variable null_matrix_variable = {0}; > +static struct d3d10_effect_variable null_string_variable = {0}; > +static struct d3d10_effect_variable null_shader_resource_variable = {0}; > +static struct d3d10_effect_variable null_render_target_view_variable = {0}; > +static struct d3d10_effect_variable null_depth_stencil_view_variable = {0}; > +static struct d3d10_effect_variable null_shader_variable = {0}; > +static struct d3d10_effect_variable null_blend_variable = {0}; > +static struct d3d10_effect_variable null_depth_stencil_variable = {0}; > +static struct d3d10_effect_variable null_rasterizer_variable = {0}; > +static struct d3d10_effect_variable null_sampler_variable = {0}; This doesn't hurt (much), but since a lot of people seem to be unaware of this I think it's worth mentioning again. Global variables as well as static (local) variables are initialized to 0 / NULL by default. The way this works in the language spec is that objects with static storage duration (i.e. the entire lifetime of the program/module) are initialized to 0 / NULL unless explicitly initialized. In practice that means global and static variables (but note that static on a global variable or function has a different meaning from static on a local variable). > +static void d3d10_null_effect_variable_init(struct d3d10_effect_variable *v, struct ID3D10EffectVariableVtbl *vtbl) > +{ > + v->vtbl = vtbl; > + v->buffer = &null_local_buffer; > + v->effect = NULL; > + v->name = NULL; > + v->semantic = NULL; > + v->buffer_offset = 0; > + v->annotation_count = 0; > + v->flag = 0; > + v->data_size = 0; > + v->type = &null_type; > + v->elements = NULL; > + v->members = NULL; > + v->annotations = NULL; > +} Most of these are redundant, since the variable will be already initialized with zeroes.

Dec. 31, 2009

Re: Tango Icons (Almost) Ready to Go!!

by André Hentschel

Joel Holdsworth schrieb: > > For this reason I think the best thing would be for me to tidy up my > project directory and upload it as a tarball somewhere. There's enough > source material there so that someone could come and adjust the icons - > even it's not as elegant as having it tied into the build process. ftp://ftp.winehq.org/pub/ would be a good solution. > Another question: When the time comes, what would be the best way to > submit the icons? I have 36 patches each of which is going to be many > kilobytes. Will the wine-patches mailing list take such large > attachments? Would it be easier to send you a git pull request from my > gitorious repo? At wineconf2009 we learned that there is something like a "patch-hole" in may, so that there are very less patches and it would be the best time to submit big patchsets :) But maybe we are already in codefreeze till then, i dont know. -- Best Regards, André Hentschel

Dec. 31, 2009

Re: [3/4] jscript: Fix various memory and reference count leaks.

by Jacek Caban

On 12/31/09 1:17 PM, Rob Shearman wrote: > 2009/12/30 Jacek Caban<jacek(a)codeweavers.com>: > >> Hi Rob, >> >> Thanks for your work on jscript. Unfortunately fixing Valgrind on jscript is >> not going to be easy. Most of your fixes are good, except clear_global part >> and "jscript: Fix a circular reference caused by object and function objects >> being able to have properties that are objects and functions." patch. I've >> sent a test showing that Windows doesn't do that. >> > I've resent the memory leak patch without the clear_global part. > Thanks. >> To fix it properly we need >> to implement a garbage collector. I've designed it in the very early days of >> jscript, but I never had time to implement it. >> > That sounds like an excellent piece of work for someone interested in > algorithms as opposed to the usual bug fixing. I don't think I have > the time to follow through on this myself at the moment. > > I can see how this would work for solving the general problem of > circular reference counts in jscript. However, I don't see how this > helps for managing the lifetime of global objects. It seems that > either the global constructors have state in which case they need to > be around for as long as the script context is, while not holding a > reference to the script context to avoid preventing it from dying, or > they don't have any state in which case they can be constructed lazily > and destroyed when the last reference is removed. > The general idea is that script_ctx_t structure is treated just like other objects by garbage collectors. This way, if there are no references stored outside script engine, as soon as engine is closed, it will be released because all its references will be circular. script_ctx_t will have to be treated a bit differently than regular objects in practice, but it's an implementation detail. Thanks, Jacek

Dec. 31, 2009

Re: Tango Icons (Almost) Ready to Go!!

by Joel Holdsworth

On Thu, 2009-12-31 at 10:20 +0100, Warren Dumortier wrote: > Thanks for all your work (is there some screenshot)? > There's no doubt that the Tango icons are good, but would it be > possible to easily make icon themes maybe, to have Oxygen icons for > example? If i understand it's hardcoded, like on Windows, but making a > theming feature is probably a lot of work right? There will be some theming work coming later when someone finishes implementing the uxtheme stuff. My icons are about getting a base theme that works well. The point of Tango is that it shouldn't look to badly out of place on Mac, KDE, Gnome or even Windows. That's a good starting point, which we can build upon if someone can implement a wine theme bridge.

Dec. 31, 2009

Re: Tango Icons (Almost) Ready to Go!!

by Joel Holdsworth

On Thu, 2009-12-31 at 11:34 +0100, Alexandre Julliard wrote: > Joel Holdsworth <joel(a)airwebreathe.org.uk> writes: > > > My final question is about what to do with my source artwork. The > > artwork has been collected from a variety of sources. Some is SVGs, some > > gimp .xcf.bz2s, and some plain PNGs. I guess these shouldn't go into the > > wine source repo, but does anyone have any bright ideas where these > > files *should* go? They'll need to be published in case the icons ever > > need to be changed in any way. > > Ideally they would all be SVG, we already have the infrastructure for > that, and for regenerating the icons from it. Though I don't know how > that would work for low bit depths, it probably needs some makefile > work. > Yes - I agree. However, I don't think it can work. It's really only the 32-bpp and 32x32 and 48x48 that can be generated from vector. The rest have all had at least some pixel work done. Some are completely done in raster. This is a reality of making icons; like hinting a font there's a lot of manual intervention at small sizes and low depths. That's one of the reasons it's taken so long to make the set. To make matters worse, a few of the icons were *acquired* as pngs or xcf.bz2s, which means I have no svg to begin with. It's all a very mixed bag. Complicating things further, I've found two bugs in icotool, which means that I have to run the compiled icons through my own icon tweaker program that fixes up the problems with the file (I've contacted the original author about the problem). For this reason I think the best thing would be for me to tidy up my project directory and upload it as a tarball somewhere. There's enough source material there so that someone could come and adjust the icons - even it's not as elegant as having it tied into the build process. Another question: When the time comes, what would be the best way to submit the icons? I have 36 patches each of which is going to be many kilobytes. Will the wine-patches mailing list take such large attachments? Would it be easier to send you a git pull request from my gitorious repo?

Dec. 31, 2009