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

Re: [PATCH] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v3).
by Henri Verbeet March 29, 2016

March 29, 2016

On 28 March 2016 at 20:02, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > v3: Add bitmap verification, use InitFromFile and other minor improvements. > Implementing InitFromFile() should be a separate patch from implementing LoadTexture(). > if (FAILED(hr = d3drm_texture_create(&object))) > return hr; > > + if (FAILED(hr = IDirect3DRMTexture_InitFromFile(&object->IDirect3DRMTexture_iface, filename))) > + { > + d3drm_texture_destroy(object); > + return hr; > + } > + > + object->d3drm = iface; > + IDirect3DRM_AddRef(iface); It would be good to back this up with tests. It would seem more natural to pass the IDirect3DRM interface to d3drm_texture_create(). If that's how it's supposed to work, you can make that change in a separate patch. > @@ -39,6 +40,9 @@ struct d3drm_texture > IDirect3DRMTexture IDirect3DRMTexture_iface; > IDirect3DRMTexture2 IDirect3DRMTexture2_iface; > IDirect3DRMTexture3 IDirect3DRMTexture3_iface; > + IDirect3DRM *d3drm; > + D3DRMIMAGE *image; > + BOOL internal_image_created; You don't really need internal_image_created, you can probably just add a destroy callback. > +HRESULT d3drm_texture_load(struct d3drm_texture *texture, IDirect3DRM *d3drm, const char *path, > + BOOL load_upside_down) DECLSPEC_HIDDEN; > + > +D3DRMIMAGE *d3drm_create_image(unsigned char *buffer, BITMAPINFO *info, BOOL palette, BOOL upside_down) DECLSPEC_HIDDEN; These are internal helper functions now. > @@ -4109,36 +4111,94 @@ static void test_load_texture(void) > > hr = IDirect3DRM_LoadTexture(d3drm1, filename, &texture1); > ok(SUCCEEDED(hr), "Test %u: Failed to load texture, hr %#x.\n", i, hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + ok(ref2 > ref1, "Test %u: expected ref2 > ref1, got ref1 = %u, ref2 = %u.\n", i, ref1, ref2); > + > + hr = IDirect3DRMTexture_InitFromFile(texture1, filename); > + ok(hr == D3DRMERR_BADOBJECT, "Test %u: Expected hr == D3DRMERR_BADOBJECT, got %#x.\n", i, hr); > + /* It's odd, but InitFromFile seems to AddRef IDirect3DRM even if it fails. */ So a test for the refcounts would be appropriate here. > +HRESULT d3drm_texture_load(struct d3drm_texture *texture, IDirect3DRM *d3drm, const char *path, BOOL load_upside_down) > +{ This is an internal helper function now and should be static. You never use "d3drm". > +D3DRMIMAGE *d3drm_create_image(unsigned char *buffer, BITMAPINFO *info, BOOL palette, BOOL upside_down) > +{ > + D3DRMPALETTEENTRY *colors; > + D3DRMIMAGE *image; > + BOOL black_used = FALSE; > + LONG w = info->bmiHeader.biWidth; > + LONG h = abs(info->bmiHeader.biHeight); > + int i, j, k; > + unsigned int idx, buffer1_idx; > + unsigned char *buffer1; > + int bpp = info->bmiHeader.biBitCount == 24 ? 32 : info->bmiHeader.biBitCount; > + int bpl = palette ? w : ((w + 3) & ~3) * bpp / 8; > + int num_colors = 0; There's not reason to use signed types for any of these. > + struct colors_24bpp > + { > + BYTE red; > + BYTE green; > + BYTE blue; > + } *color; > + color = (struct colors_24bpp *)buffer; > + > + if (bpl * h > UINT_MAX) > + { > + return NULL; > + } This doesn't work. If "bpl * h" would be larger than UINT_MAX it would overflow before the comparison. In fact, strictly speaking things become implementation defined above INT_MAX already, since you're using signed types for "bpl" and "h". What you'd typically do is something like "if (h > UINT_MAX / bpl)". Note that the calculation of "bpl" itself can overflow as well. So you'd need something like "if (align(w, 4) > UINT_MAX / (bpp / 8))" there as well. > + if (!(colors = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 256 * sizeof(*colors)))) > + { > + WARN("Not enough memory to allocate palette, returning NULL.\n"); > + return NULL; > + } > + > + > + if (!(image = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*image)))) > + { > + WARN("Not enough memory to allocate image struct, returning NULL.\n"); > + return NULL; > + } You probably don't need HEAP_ZERO_MEMORY for either of these. You certainly don't for "colors", and you should probably just initialise the few fields in "image" that you don't already. You also leak "colors" if the allocation for "image" fails. The indentation for the WARN is wrong. > + if (!(image->buffer1 = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, bpl * h))) > + { > + WARN("Not enough memory to allocate image buffer, returning NULL.\n"); > + return NULL; > + } You don't need HEAP_ZERO_MEMORY here if you're going to memset() it again below. You leak "colors" and "image" on failure. > + buffer1 = image->buffer1; > + memset(buffer1, 255, sizeof(unsigned char) * bpl * h); I think 0xff is clearer than 255. The "sizeof(unsigned char)" doesn't add much. > + if (!(image->palette = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, num_colors * sizeof(*image->palette)))) > + { > + WARN("Not enough memory to allocate image palette, returning NULL.\n"); > + return NULL; > + } Like above, you use HEAP_ZERO_MEMORY here, but immediately memcpy() over it. You leak on error. > + if (!(image->palette = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 256 * sizeof(*image->palette)))) > + { > + WARN("Not enough memory to allocate image palette, returning NULL.\n"); > + return NULL; > + } Leak on error. > static HRESULT WINAPI d3drm_texture1_InitFromFile(IDirect3DRMTexture *iface, const char *filename) > { > - FIXME("iface %p, filename %s stub!\n", iface, debugstr_a(filename)); > + struct d3drm_texture *object = impl_from_IDirect3DRMTexture(iface); I'd suggest "texture" instead of "object". > + if (object->d3drm) > + { > + /* InitFromFile seems to AddRef IDirect3DRM even if it fails. */ > + IDirect3DRM_AddRef(object->d3drm); > + } This is very suspicious, since you always assign "object->d3drm" after calling InitFromFile(). It's not backed up by tests either.

2 4

Re: [v7 2/7] d3dx9: Implement preshader parsing.
by Matteo Bruni March 29, 2016

March 29, 2016

2016-03-28 9:20 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> > --- > Changes > - Changed opcode function to take double arguments and return double Good catch. > +static struct op_info pres_op_info[] = > +{ > + {0x000, "nop", 0, 0, NULL }, /* PRESHADER_OP_NOP */ > + {0x100, "mov", 1, 0, pres_mov}, /* PRESHADER_OP_MOV */ > +}; I think this can be const. > +struct d3dx_pres_ins > +{ > + enum pres_ops op; > + /* first input argument is scalar, > + scalar component is propagated */ > + BOOL scalar_op; > + unsigned int component_count; > + struct d3dx_pres_operand inputs[3]; The maximum number of input operands could use a #define. Not a huge deal though. > +static void regstore_free_tables(struct d3dx_regstore *rs) > +{ > + unsigned int i; > + > + for (i = PRES_REGTAB_FIRST; i <= PRES_REGTAB_LAST; ++i) > + { > + if (rs->tables[i]) > + HeapFree(GetProcessHeap(), 0, rs->tables[i]); > + if (rs->table_value_set[i]) > + HeapFree(GetProcessHeap(), 0, rs->table_value_set[i]); > + } > +} You don't need to check for non-NULL, HeapFree() handles NULL arguments just fine. > +static unsigned int *find_bytecode_comment(unsigned int *ptr, unsigned int fourcc) > +{ > + while ((*ptr & 0xffff) == 0xfffe) > + { > + if (*(ptr + 1) == fourcc) > + return ptr + 2; > + ptr += 1 + (*ptr >> 16); > + } > + return NULL; > +} This is probably paranoid but in theory a broken or malicious effect could send you rummaging outside of the bytecode buffer so all the offsets should be checked. I don't think it's critical in practice i.e. I'll probably sleep just fine if you decide to ignore this issue... > +static unsigned int *parse_pres_arg(unsigned int *ptr, struct d3dx_pres_operand *opr) > +{ > + static const enum pres_reg_tables reg_table[8] = > + { > + PRES_REGTAB_COUNT, PRES_REGTAB_IMMED, PRES_REGTAB_CONST, PRES_REGTAB_COUNT, > + PRES_REGTAB_OCONST, PRES_REGTAB_OBCONST, PRES_REGTAB_OICONST, PRES_REGTAB_REG Matter of taste, so feel free to ignore this, but PRES_REGTAB_REG sounds a bit vague to me. I'd go with something like PRES_REGTAB_TEMP. > + if (input_count != pres_op_info[i].input_count) > + { > + FIXME("Actual input args %u, expected %u, instruction %s.\n", input_count, > + pres_op_info[i].input_count, pres_op_info[i].mnem); > + return NULL; > + } > + for (i = 0; i < input_count; ++i) > + { > + ptr = parse_pres_arg(ptr, &ins->inputs[i]); > + if (!ptr) > + return NULL; > + } Another pretty paranoid potential check, here you could verify that input_count is < ARRAY_SIZE(ins->inputs). Of course that could only fail if we encounter some instruction with more than 3 components AND we update pres_op_info BUT we forget to update struct d3dx_pres_ins, but I don't think it would hurt to be safe... > + for (i = 0; i < pres->ins_count; ++i) > + { > + unsigned int table; > + > + for (j = 0; j < pres_op_info[pres->ins[i].op].input_count; ++j) > + { > + table = pres->ins[i].inputs[j].table; > + max_offset = get_reg_offset(table, pres->ins[i].inputs[j].offset + pres->ins[i].component_count - 1); > + pres->regs.table_sizes[table] = max(pres->regs.table_sizes[table], max_offset + 1); > + } > + table = pres->ins[i].output.table; > + max_offset = get_reg_offset(table, pres->ins[i].output.offset + pres->ins[i].component_count - 1); > + pres->regs.table_sizes[table] = max(pres->regs.table_sizes[table], max_offset + 1); > + } > + update_table_sizes_consts(pres->regs.table_sizes, &pres->inputs); It probably makes sense to add a small update_table_size() helper (or similar), the "same" 3 lines are repeated in the loop for the input operands, for the output operand and in update_table_sizes_consts(). > + for (i = PRES_REGTAB_IMMED + 1; i <= PRES_REGTAB_LAST; ++i) It depends on what is coming up next but maybe it would make sense to add an enum for "PRES_REGTAB_IMMED + 1" (incidentally, PRES_REGTAB_FIRST is never used in this patch series). > + { > + TRACE("table_sizes[%u] %u.\n", i, peval->pres.regs.table_sizes[i]); That trace looks a bit like a debugging leftover. > + if (FAILED(regstore_alloc_table(&peval->pres.regs, i))) > + { > + hr = E_OUTOFMEMORY; > + goto err_out; > + } > + } > + > + if (TRACE_ON(d3dx)) > + dump_bytecode(byte_code, byte_code_size); > + > + *peval_out = peval; > + TRACE("retval %u, *peval_out %p.\n", D3D_OK, *peval_out); Same with this. This one in particular doesn't seem worth keeping. > + return D3D_OK; > + > +err_out: > + FIXME("Error creating parameter evaluator.\n"); > + d3dx_free_param_eval(peval); > *peval_out = NULL; > - return E_NOTIMPL; > + TRACE("retval %u, *peval_out %p.\n", hr, *peval_out); > + return hr; > +} You could print the HRESULT in the FIXME (e.g. FIXME("Error creating parameter evaluator, returning %#x.\n", hr)). Tracing the value of *peval_out doesn't seem particularly worthwhile. > +static void d3dx_free_const_tab(struct d3dx_const_tab *ctab) > +{ > + if (ctab->inputs) > + HeapFree(GetProcessHeap(), 0, ctab->inputs); > + if (ctab->inputs_param) > + HeapFree(GetProcessHeap(), 0, ctab->inputs_param); > + if (ctab->ctab) > + ID3DXConstantTable_Release(ctab->ctab); > +} > + > +static void d3dx_free_preshader(struct d3dx_preshader *pres) > +{ > + if (pres->ins) > + HeapFree(GetProcessHeap(), 0, pres->ins); > + > + regstore_free_tables(&pres->regs); > + d3dx_free_const_tab(&pres->inputs); > } You can drop all those ifs (I think there are a few more of them in the middle of the patch I haven't specifically mentioned).

2 5

Re: [v2 PATCH 2/3] d2d1/tests: Basic test for ID2D1DCRenderTarget creation
by Henri Verbeet March 29, 2016

March 29, 2016

On 29 March 2016 at 01:21, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + static D2D1_PIXEL_FORMAT invalid_formats[] = > + { > + { DXGI_FORMAT_UNKNOWN, D2D1_ALPHA_MODE_PREMULTIPLIED }, > + { DXGI_FORMAT_B8G8R8A8_UNORM, D2D1_ALPHA_MODE_UNKNOWN }, > + { DXGI_FORMAT_R8G8B8A8_UNORM, D2D1_ALPHA_MODE_PREMULTIPLIED }, > + }; I should have noticed before, but this should be const.

2 1

Re: [PATCH 2/5] ddraw/tests: Add a test for color varyings clamping.
by Henri Verbeet March 29, 2016

March 29, 2016

On 28 March 2016 at 23:03, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + hr = IDirect3DDevice7_GetDirect3D(device, &d3d); > + ok(SUCCEEDED(hr), "Failed to get d3d interface, hr %#x.\n", hr); I suppose this is borrowed from test_shademode() where it's used to create the vertex buffers, but you're not using "d3d" anywhere here.

1 0

Re: [PATCH] msvcr120/tests: Add critical section test.
by Piotr Caban March 28, 2016

March 28, 2016

Hi YongHao, On 03/18/16 17:24, YongHao Hu wrote: > dlls/msvcr120/tests/msvcr120.c | 300 > +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 300 insertions(+) I don't think this is a good approach for adding tests of critical_section class. Executing tons of enter/leave calls is not really testing much. Your test_critical_section_lock tests will probably pass if you comment all critical section related calls out (it passed on my computer in 10 consecutive runs, never failed, probably it's because the code was optimized during compilation). Testing 5s/6s timeouts is also not a good idea. Because of it the tests are running much longer. It would be much better if you test following things: - just check some basic functionality of enter/leave: enter cs in main thread, start new thread that tries to enter it as well, wait for 100ms and check that it was not able to enter the cs, then leave cs in main thread and wait for thread to enter cs and finish - check some basic functionality of try_lock: use it to lock the cs, check if it fails on locked cs Also the tests failed on testbot, I was not checking why. Thanks, Piotr

3 3

Re: [PATCH 2/5] ddraw/tests: Add a test for color varyings clamping.
by Marvin March 28, 2016

March 28, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=21748 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH 2/3] d2d1/tests: Basic test for ID2D1DCRenderTarget creation
by Henri Verbeet March 28, 2016

March 28, 2016

On 28 March 2016 at 22:18, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + hr = ID2D1Factory_CreateDCRenderTarget(factory, &desc, &rt); > + todo_wine > + ok(hr == D2DERR_UNSUPPORTED_PIXEL_FORMAT, "Failed to create target, hr %#x.\n", hr); ... > + hr = ID2D1DCRenderTarget_EndDraw(rt, NULL, NULL); > + ok(hr == D2DERR_WRONG_STATE, "EndDraw() failed, hr %#x.\n", hr); Those messages are a bit misleading. (For what it's worth, we usually use "Got unexpected hr %#x.\n" for those.)

1 0

Re: [PATCH] d2d1: Added a stub implementation for ID2D1DCRenderTarget
by Nikolay Sivov March 28, 2016

March 28, 2016

Please ignore this one for now.

1 0

Re: [PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).
by Henri Verbeet March 28, 2016

March 28, 2016

On 20 March 2016 at 19:24, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > - FIXME("iface %p, filename %s, texture %p stub!\n", iface, debugstr_a(filename), texture); > + TRACE("iface %p, filename %s, texture %p\n", iface, debugstr_a(filename), texture); Missing period. > @@ -853,15 +859,19 @@ static HRESULT WINAPI d3drm2_CreateUserVisual(IDirect3DRM2 *iface, > static HRESULT WINAPI d3drm2_LoadTexture(IDirect3DRM2 *iface, > const char *filename, IDirect3DRMTexture2 **texture) > { > - struct d3drm_texture *object; > + struct d3drm *d3drm = impl_from_IDirect3DRM2(iface); > + IDirect3DRMTexture3 *texture3; > HRESULT hr; > > - FIXME("iface %p, filename %s, texture %p stub!\n", iface, debugstr_a(filename), texture); > + TRACE("iface %p, filename %s, texture %p.\n", iface, debugstr_a(filename), texture); > > - if (FAILED(hr = d3drm_texture_create(&object))) > + if (FAILED(hr = IDirect3DRM3_LoadTexture(&d3drm->IDirect3DRM3_iface, filename, &texture3))) > return hr; > > - *texture = &object->IDirect3DRMTexture2_iface; > + hr = IDirect3DRMTexture3_QueryInterface(texture3, &IID_IDirect3DRMTexture2, (void**)texture); > + IDirect3DRMTexture3_Release(texture3); > + if (FAILED(hr)) > + return hr; > > return D3DRM_OK; > } This is probably ok, but you may want to consider just introducing a helper function instead. I.e.: if (FAILED(hr = d3drm_load_texture(d3drm, filename, TRUE, &object))) return hr; IDirect3DRMTexture2_AddRef(*texture = &object->IDirect3DRMTexture2_iface); return D3DRM_OK; What happens when d3drm_texture_load() is called multiple times on the same texture? Should that be possible? > +void d3drm_texture_destroy(struct d3drm_texture *texture); Missing DECLSPEC_HIDDEN. > +HRESULT d3drm_texture_load(struct d3drm_texture *texture, IDirect3DRM *d3drm, const char *path, BOOL load_upside_down) DECLSPEC_HIDDEN; This line is a bit long. Try to stick to 120 columns as a maximum, preferably a bit less. > +D3DRMIMAGE *d3drm_create_image(unsigned char *buffer, BITMAPINFO *info, BOOL palette, BOOL upside_down); Missing DECLSPEC_HIDDEN. > @@ -4103,24 +4105,34 @@ static void test_load_texture(void) > > hr = IDirect3DRM_LoadTexture(d3drm1, filename, &texture1); > ok(SUCCEEDED(hr), "Test %u: Failed to load texture, hr %#x.\n", i, hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %u, ref2 = %u.\n", ref1, ref2); The message should mention which test (i.e., "i") failed. > d3drm_img = IDirect3DRMTexture_GetImage(texture1); > - todo_wine ok(!!d3drm_img, "Test %u: Failed to get image.\n", i); > + ok(!!d3drm_img, "Test %u: Failed to get image.\n", i); > if (d3drm_img) > test_bitmap_data(i * 4, d3drm_img, FALSE, tests[i].w, tests[i].h, tests[i].palettized); Now that IDirect3DRMTexture_GetImage() succeeds, you can remove the "if (d3drm_img)". > +void d3drm_texture_destroy(struct d3drm_texture *texture) > +{ > + if (texture->image) > + { > + TRACE("Releasing attached members.\n"); > + HeapFree(GetProcessHeap(), 0, texture->image->buffer1); > + if(texture->image->palette) Missing space between "if" and "(". > + HeapFree(GetProcessHeap(), 0, texture->image->palette); > + HeapFree(GetProcessHeap(), 0, texture->image); This seems a bit suspicious. Supposedly the "image" argument to d3drm3_CreateTexture() can be used to create a texture on an existing image. The documentation isn't very explicit about it, but suggests that the image data isn't copied in that case. So I'm not sure the texture is supposed to be responsible for destroying the image. In general I think it's not entirely clear how things like CreateTexture(), LoadTexture() and InitFromFile() etc. are supposed to interact. > +HRESULT d3drm_texture_load(struct d3drm_texture *texture, IDirect3DRM *d3drm, const char *path, BOOL load_upside_down) > +{ > + BITMAPINFO *info; > + BITMAPFILEHEADER *bmp_header; > + unsigned char *buffer; > + DWORD size; > + HANDLE hfile, hmapping; > + > + hfile = CreateFileA(path, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0); > + if (hfile == INVALID_HANDLE_VALUE) > + return D3DRMERR_BADFILE; > + > + size = GetFileSize(hfile, NULL); > + if (size == INVALID_FILE_SIZE) > + { > + DeleteObject(hfile); > + return D3DRMERR_BADVALUE; > + } You never use "size" after this, but you probably should. I also think you meant CloseHandle() instead of DeleteObject(). > + buffer = MapViewOfFile(hmapping, FILE_MAP_READ, 0, 0, 0); > + if (buffer == NULL) "if (!buffer)", or even "if (!(buffer = MapViewOfFile(...)))" > + bmp_header = (BITMAPFILEHEADER *)buffer; > + info = (BITMAPINFO *) (buffer + sizeof(*bmp_header)); Or just "info = (BITMAPINFO *)bmp_header + 1;". You should validate that this is actually a BMP file. You should also check which version of the BITMAPINFOHEADER structure the file has. > +D3DRMIMAGE *d3drm_create_image(unsigned char *buffer, BITMAPINFO *info, BOOL palette, BOOL upside_down) > +{ > + D3DRMPALETTEENTRY *colors = (D3DRMPALETTEENTRY *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 257 * sizeof(*colors)); Is "257" there intentional? The cast is unnecessary. HeapAlloc() can fail. Do you need HEAP_ZERO_MEMORY here? > + D3DRMIMAGE *image; > + BOOL black_used = FALSE; > + LONG w = info->bmiHeader.biWidth; > + LONG h = abs(info->bmiHeader.biHeight); > + int i, j, k; > + unsigned int idx, buffer1_idx; > + unsigned char *buffer1; > + int bpp = info->bmiHeader.biBitCount == 24 ? 32 : info->bmiHeader.biBitCount; > + int bpl = palette ? w : ((w + 3) & ~3) * bpp / 8; > + int num_colors = 0; > + struct colors_24bpp > + { > + BYTE red; > + BYTE green; > + BYTE blue; > + } *color; > + color = (struct colors_24bpp *)buffer; > + > + image = (D3DRMIMAGE *)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*image)); > + image->buffer1 = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(unsigned char) * bpl * h); This is unsafe. Consider e.g. what happens when the header gives you 0x10000 for width and height. > + buffer1 = image->buffer1; > + memset(buffer1, 255, sizeof(unsigned char) * bpl * h); You just initialised the memory with HEAP_ZERO_MEMORY, and now you're overwriting it again. At least one of these two initialisations is unnecessary, and quite possibly both of them.

3 21

Re: [PATCH 10/10] jscript: Find Function.arguments on the stack instead of storing it in FunctionInstance object.
by Marvin March 28, 2016

March 28, 2016

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=21743 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

1 0