July 2011 - Wine-Devel - list.winehq.org

Re: Random crashes while running (cmd) test runner [update backtrace]

by Frédéric Delanoy

#0 0x7bc481f2 in HEAP_MakeInUseBlockFree (subheap=0x110014, pArena=0x1106a8) at heap.c:640 #1 0x7bc4b7f5 in RtlFreeHeap (heap=0x110000, flags=2, ptr=0x1106b0) at heap.c:1757 #2 0x7bc38b12 in read_directory_stat (fd=13, io=0x33dbd0, buffer=0x1116c8, length=8192, single_entry=0 '\000', mask=0x1116ac, restart_scan=1 '\001', class=FileBothDirectoryInformation) at directory.c:1936 #3 0x7bc38f3b in NtQueryDirectoryFile (handle=0x24, event=0x0, apc_routine=0, apc_context=0x0, io=0x33dbd0, buffer=0x1116c8, length=8192, info_class=FileBothDirectoryInformation, single_entry=0 '\000', mask=0x1116ac, restart_scan=1 '\001') at directory.c:2012 #4 0x7b8400aa in FindFirstFileExW (filename=0x33dccc, level=FindExInfoStandard, data=0x33e4cc, search_op=FindExSearchNameMatch, filter=0x0, flags=0) at file.c:1864 #5 0x7b840a69 in FindFirstFileW (lpFileName=0x33dccc, lpFindData=0x33e4cc) at file.c:2083 #6 0x7b859ba6 in GetLongPathNameW (shortpath=0x33ee68, longpath=0x33e780, longlen=260) at path.c:362 #7 0x7b861765 in create_startup_info (filename=0x33ee68, cmdline=0x111348, cur_dir=0x0, env=0x0, flags=0, startup=0x33f928, info_size=0x33ea40) at process.c:1595 #8 0x7b86256c in create_process (hFile=0x20, filename=0x33ee68, cmd_line=0x111348, env=0x0, cur_dir=0x0, psa=0x0, tsa=0x0, inherit=1, flags=0, startup=0x33f928, info=0x33fa3c, unixdir=0x111540 "/home/fred/.wine-tmp/dosdevices/z:/home/fred/sources/wine-git", binary_info=0x33f070, exec_only=0) at process.c:1926 #9 0x7b8638b0 in create_process_impl (app_name=0x33f1a8, cmd_line=0x111348, process_attr=0x0, thread_attr=0x0, inherit=1, flags=0, env=0x0, cur_dir=0x0, startup_info=0x33f928, info=0x33fa3c) at process.c:2274 #10 0x7b864175 in CreateProcessW (app_name=0x33f1a8, cmd_line=0x111348, process_attr=0x0, thread_attr=0x0, inherit=1, flags=0, env=0x0, cur_dir=0x0, startup_info=0x33f928, info=0x33fa3c) at process.c:2388 #11 0x7b862f95 in create_cmd_process (filename=0x33f628, cmd_line=0x111328, env=0x0, cur_dir=0x0, psa=0x0, tsa=0x0, inherit=1, flags=0, startup=0x33f928, info=0x33fa3c) at process.c:2100 #12 0x7b863c71 in create_process_impl (app_name=0x0, cmd_line=0x111328, process_attr=0x0, thread_attr=0x0, inherit=1, flags=0, env=0x0, cur_dir=0x0, startup_info=0x33f928, info=0x33fa3c) at process.c:2305 #13 0x7b864068 in CreateProcessA (app_name=0x0, cmd_line=0x33fa73 "test.cmd", process_attr=0x0, thread_attr=0x0, inherit=1, flags=0, env=0x0, cur_dir=0x0, startup_info=0x33f9f8, info=0x33fa3c) at process.c:2368 #14 0x7effb19e in run_cmd (cmd_data=0x110688 "@echo off\necho should fail\n\ndir\n\022", cmd_size=33) at batch.c:95 #15 0x7effb9f4 in run_test (cmd_data=0x7efff52c "@echo off\necho should fail\n\ndir\n\n", cmd_size=28, exp_data=0x7efff548 "dir\n\n", exp_size=5) at batch.c:239 #16 0x7effbe46 in test_enum_proc (module=0x7eff0000, type=0x7effd4ab "TESTCMD", name=0x110668 "TEST_BUILTINS.CMD", param=0) at batch.c:317 #17 0x7b86d748 in EnumResourceNamesA (hmod=0x7eff0000, type=0x7effd4ab "TESTCMD", lpfun=0x7effbd43 <test_enum_proc>, lparam=0) at resource.c:345 #18 0x7effc008 in func_batch () at batch.c:353 #19 0x7effcc92 in run_test (name=0x7effd745 "batch") at ../../../include/wine/test.h:556 #20 0x7effd057 in main (argc=1, argv=0x1103e0) at ../../../include/wine/test.h:616 #21 0x7effd136 in __wine_spec_exe_entry (peb=0x7ffdf000) at exe_entry.c:36 #22 0x7b860008 in call_process_entry () at process.c:1035 #23 0x7b86014f in start_process (peb=0x7ffdf000) at process.c:1087 #24 0x7bc7f22c in call_thread_func () at signal_i386.c:2473 #25 0x7bc7f26a in call_thread_entry_point (entry=0x7b86000a <start_process>, arg=0x7ffdf000) at signal_i386.c:2499 #26 0x7bc542cf in start_process (kernel_start=0x7b86000a) at loader.c:2612 #27 0xf75c0b95 in wine_call_on_stack () at port.c:60 #28 0xf75c0b73 in wine_switch_to_stack (func=0x7bc542a9 <start_process>, arg=0x7b86000a, stack=0x340000) at port.c:59

July 3, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Sun, Jul 3, 2011 at 8:41 AM, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote: > On Sat, Jul 2, 2011 at 1:01 PM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: >> +static HRESULT init_edge_face_map(struct edge_face_map *edge_face_map, CONST DWORD *index_buffer, CONST DWORD *point_reps, CONST DWORD num_faces) >> +{ > ... >> + TRACE("(%p, %p, %p, %d)\n", edge_face_map, index_buffer, point_reps, num_faces); > > A TRACE call for an internal initialization function like this seems > unnecessary. They are commonly provided for external functions since > it captures application behavior. Ok, I've removed them. >> + if (!point_reps) /* Identity point reps */ >> + { >> + id_point_reps = generate_identity_point_reps(num_faces, num_vertices); >> + if (!id_point_reps) >> + { >> + hr = E_OUTOFMEMORY; >> + goto cleanup; > ... >> + hr = iface->lpVtbl->LockIndexBuffer(iface, D3DLOCK_READONLY, &ib_ptr); >> + if (FAILED(hr)) goto cleanup; > ... >> +cleanup: >> + HeapFree(GetProcessHeap(), 0, id_point_reps); >> + if (indices_are_16_bit) HeapFree(GetProcessHeap(), 0, ib); >> + free_edge_face_map(&edge_face_map); >> + iface->lpVtbl->UnlockIndexBuffer(iface); >> + return hr; >> } > > The index buffer is unconditionally unlocked in the cleanup code, but > goto cleanup can now be called before the index buffer is locked. I've added a check to see if it's locked. >> +static DWORD *generate_identity_point_reps(DWORD num_faces, DWORD num_vertices) >> +{ >> + DWORD *id_point_reps; >> + DWORD i; >> + >> + TRACE("(%d, %d)\n", num_faces, num_vertices); >> + >> + id_point_reps = HeapAlloc(GetProcessHeap(), 0, 3 * num_faces * sizeof(*id_point_reps)); >> + if (!id_point_reps) >> + return NULL; >> + >> + for (i = 0; i < num_vertices; i++) >> + { >> + id_point_reps[i] = i; >> + } >> + for (i = num_vertices; i < 3 * num_faces; i++) >> + { >> + id_point_reps[i] = -1; >> + } >> + >> + return id_point_reps; >> +} > > Why are there exra point reps allocated with -1 value? Won't only > num_vertices point_reps get used? Yes that was a mistake. Only num_vertices are used and not 3*num_faces. I have also removed some unnecessary -1 checks.

July 3, 2011

Re: Glitch-free iTunes?

by Damjan Jovanovic

On Sun, Jul 3, 2011 at 4:49 AM, Keith Curtis <keithcu(a)gmail.com> wrote: > >> So: yeah, we know it's an important app. But it's hard. >> Feel free to help out. >> - Dan > > Hi; > > I am glad to hear you say that iTunes is an "important" app, but I don't > understand what you mean because it has never worked. > > You don't need my help. You've got a big group making many good fixes. It is > just that priority is being ignored or something. Failure is not from lack > of effort, but from planning. Hi Keith Having worked at Microsoft, you of all people should appreciate the size and complexity of the driver architecture on Windows. So I would say that "failure" is mostly from the scale of the problem to be solved. My attempts at adding USB support to Wine have been painful and slow. In 2006 my first patches ever submitted to Wine dealt with some SETUPAPI.DLL bugs. By around 2007 hacks I made to Wine and the Linux kernel to emulate USBSCAN.SYS allowed my Windows-only user-space USB scanner driver to work in Ubuntu 6.06. Some of those hacks were eventually cleaned up and made their way into Wine's STI.DLL in 2009, but my kernel patch never worked on any other kernel version, and I doubt either Wine or the Linux kernel would accept the dodgy code I had to use. I began investigating the option of implementing USBSCAN in a user-space driver with something like CUSE, but then Wine got a rudimentary NTOSKRNL.EXE and the ability to load Windows SYS files. Since then the idea was to implement everything in Wine, and use libusb for USB I/O. In 2010 I added some USBD.SYS functions and some USB headers to Wine. Later I tried to add libusb support, USB device monitoring, and basic on-demand driver loading infrastructure, but none of that was accepted into Wine for various reasons. Currently I am trying to gradually generalize driver loading in Wine. Then I hope to add loading drivers as USB devices are plugged in. Then add libusb support. Then actually add basic USB I/O. Then get ReadFile/WriteFile working for drivers. And even then, there's still higher-level drivers to write (eg. USBSCAN.SYS), and many SETUPAPI.DLL bugs and features like support for class installers that have to be added before drivers will even install properly. And then we hope they don't start using too many of the unimplemented functions in NTOSKRNL.EXE. So it's slow going and there's a lot to do, and few Wine developers seem to care. One can only hope that when some devices start working, it will generate new interest in Wine (and Linux), and Wine will get many more patches :-). > Let's win! > > -Keith > http://keithcu.com/ > > > > > Damjan

July 3, 2011

Re: Updated Clang static analysis results / Valgrind update

by Frédéric Delanoy

On Sun, Jul 3, 2011 at 04:15, Austin English <austinenglish(a)gmail.com> wrote: > Web space usage was getting a bit high, so I've uploaded a tarball to > a file download service: > http://www.sendspace.com/file/5hot36 > > austin(a)aw21 ~ $ sha1sum scan-build-2011-07-02.tar.bz2 > ac3cb3920ef97641fff1f5376f8136cef01f15bf scan-build-2011-07-02.tar.bz2 FWIW, you could use xz instead of bzip2 to further reduce the download size (54 MiB) I got the size down to 46 MiB using default settings, and 25 MiB using max compression (xz -9) Frédéric

July 3, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Henri Verbeet

On 30 June 2011 18:42, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > Btw I just searched source.winehq.org for hash_table and found several > hits in different dlls. I think it would be nice if they could all use > the same implementation like list.h and rbtree.h. Maybe. It would probably need to be looked at for each case separately.

July 3, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Dylan Smith

On Sat, Jul 2, 2011 at 1:01 PM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > Thank you for the good review. Glad you appreciate them. Here is another. > +static HRESULT init_edge_face_map(struct edge_face_map *edge_face_map, CONST DWORD *index_buffer, CONST DWORD *point_reps, CONST DWORD num_faces) > +{ ... > + TRACE("(%p, %p, %p, %d)\n", edge_face_map, index_buffer, point_reps, num_faces); A TRACE call for an internal initialization function like this seems unnecessary. They are commonly provided for external functions since it captures application behavior. > + if (!point_reps) /* Identity point reps */ > + { > + id_point_reps = generate_identity_point_reps(num_faces, num_vertices); > + if (!id_point_reps) > + { > + hr = E_OUTOFMEMORY; > + goto cleanup; ... > + hr = iface->lpVtbl->LockIndexBuffer(iface, D3DLOCK_READONLY, &ib_ptr); > + if (FAILED(hr)) goto cleanup; ... > +cleanup: > + HeapFree(GetProcessHeap(), 0, id_point_reps); > + if (indices_are_16_bit) HeapFree(GetProcessHeap(), 0, ib); > + free_edge_face_map(&edge_face_map); > + iface->lpVtbl->UnlockIndexBuffer(iface); > + return hr; > } The index buffer is unconditionally unlocked in the cleanup code, but goto cleanup can now be called before the index buffer is locked. > +static DWORD *generate_identity_point_reps(DWORD num_faces, DWORD num_vertices) > +{ > + DWORD *id_point_reps; > + DWORD i; > + > + TRACE("(%d, %d)\n", num_faces, num_vertices); > + > + id_point_reps = HeapAlloc(GetProcessHeap(), 0, 3 * num_faces * sizeof(*id_point_reps)); > + if (!id_point_reps) > + return NULL; > + > + for (i = 0; i < num_vertices; i++) > + { > + id_point_reps[i] = i; > + } > + for (i = num_vertices; i < 3 * num_faces; i++) > + { > + id_point_reps[i] = -1; > + } > + > + return id_point_reps; > +} Why are there exra point reps allocated with -1 value? Won't only num_vertices point_reps get used?

July 3, 2011

Re: kernel32/tests: remove a few CloseHandle calls on a HMODULE that don't make any sense

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=12163 Your paranoid android. === WNT4WSSP6 (32 bit module) === module.c:356: Test failed: Expected ERROR_FILE_NOT_FOUND, got 1006

July 3, 2011

Re: Glitch-free iTunes?

by James McKenzie

On 7/2/11 7:49 PM, Keith Curtis wrote: > > So: yeah, we know it's an important app. But it's hard. > Feel free to help out. > - Dan > > > Hi; > > I am glad to hear you say that iTunes is an "important" app, but I > don't understand what you mean because it has never worked. > > You don't need my help. You've got a big group making many good fixes. > It is just that priority is being ignored or something. Failure is not > from lack of effort, but from planning. > > Keith: Maybe you missed Dan's point. iTunes, for a while, did work. Most of the work to get it to work has been by volunteers and it remains up to the volunteer side of the project to 'make it so'. Syncing an iPod did work as far as I knew using the USB device patches. Also, this is, mainly, an all-volunteer effort. I, for instance, picked up three richedit functions that are very near and dear to the functioning of several programs that I use. There is a long known work-around, but I would like to see appropriate code included in the Wine project so that the work-around is no longer needed. iTunes on the Linux platform may or may not be forthcoming. Making iTunes work on any flavor/distribution of Linux might take a very interested and talented user with programming skills in 'c' to generate the code and get appropriate fixes made in the Wine code. Attempts have been made and some successes gained, but more needs to be done and mostly by a small staff of volunteers. Project priorities might say 'make this work' but without appropriately interested and skilled volunteers, iTunes might not be working under Linux anytime soon. James McKenzie

July 3, 2011

Re: Glitch-free iTunes?

by Keith Curtis

> So: yeah, we know it's an important app. But it's hard. > Feel free to help out. > - Dan > Hi; I am glad to hear you say that iTunes is an "important" app, but I don't understand what you mean because it has never worked. You don't need my help. You've got a big group making many good fixes. It is just that priority is being ignored or something. Failure is not from lack of effort, but from planning. Let's win! -Keith http://keithcu.com/

July 3, 2011

Updated Clang static analysis results / Valgrind update

by Austin English

Web space usage was getting a bit high, so I've uploaded a tarball to a file download service: http://www.sendspace.com/file/5hot36 austin(a)aw21 ~ $ sha1sum scan-build-2011-07-02.tar.bz2 ac3cb3920ef97641fff1f5376f8136cef01f15bf scan-build-2011-07-02.tar.bz2 to use, just extract and open in your favorite browser: $ firefox index.html this was run against Clang from svn: clang version 3.0 (trunk 134320) Please send me any false positives that you'd like me to report upstream. Cheers, Austin P.S. For those of you wanting Valgrind results, I'm currently hitting a nasty Valgrind bug, waiting on upstream to fix: https://bugs.kde.org/show_bug.cgi?id=275673 (Thanks to Andrew N for finding the faulty commit)

July 3, 2011