Student preparing for GSoC
Hello, I am a computer science student at the City College of New York. I have used Linux for a few years now and have frequently relied on Wine to run windows applications, so the opportunity to contribute to Wine is exciting to me. I have successfully built wine from source and ran Ski Free on it to test if it worked. Next I wanted to try and find some of the fixmes that were popping up so I could attempt my first patch, however I am having trouble finding where exactly in the source the fixme's are arising. Maybe It's obvious and I'm just too tired right now to figure it out, but I would be very appreciative if someone could point me in the right direction with this. While I have been learning computer science for years now, I have not yet contributed to an open source project. I am very eager to learn and become familiar with the process. Thank you! Kieran Duggan
On 15/03/18 01:38, Kieran Duggan wrote:
Hello, I am a computer science student at the City College of New York. I have used Linux for a few years now and have frequently relied on Wine to run windows applications, so the opportunity to contribute to Wine is exciting to me.
I have successfully built wine from source and ran Ski Free on it to test if it worked. Next I wanted to try and find some of the fixmes that were popping up so I could attempt my first patch, however I am having trouble finding where exactly in the source the fixme's are arising. Maybe It's obvious and I'm just too tired right now to figure it out, but I would be very appreciative if someone could point me in the right direction with this.
While I have been learning computer science for years now, I have not yet contributed to an open source project. I am very eager to learn and become familiar with the process.
Thank you! Kieran Duggan
Hello Kieran, and thanks for your interest in Wine and GSoC! A fixme: message prints out the name of its component, then the function in question, and then some further information. For example: 0041:fixme:ntdll:NtLockFile I/O completion on lock not implemented yet is printed in the NtLockFile() function, which is part of ntdll. It's printed in the source by a FIXME macro: dlls/ntdll/file.c:3424: FIXME("I/O completion on lock not implemented yet\n"); In general you can just grep for the function name. I hope this helps. Also please feel free to ask about any specific FIXME or bug before trying to tackle it. A fair number of features are as yet unimplemented because they're more work than they're worth. ἔρρωσο, Zeb
Am 15.03.2018 um 17:43 schrieb Zebediah Figura:
On 15/03/18 01:38, Kieran Duggan wrote:
Hello, I am a computer science student at the City College of New York. I have used Linux for a few years now and have frequently relied on Wine to run windows applications, so the opportunity to contribute to Wine is exciting to me.
I have successfully built wine from source and ran Ski Free on it to test if it worked. Next I wanted to try and find some of the fixmes that were popping up so I could attempt my first patch, however I am having trouble finding where exactly in the source the fixme's are arising. Maybe It's obvious and I'm just too tired right now to figure it out, but I would be very appreciative if someone could point me in the right direction with this.
While I have been learning computer science for years now, I have not yet contributed to an open source project. I am very eager to learn and become familiar with the process.
Thank you! Kieran Duggan
Hello Kieran, and thanks for your interest in Wine and GSoC!
A fixme: message prints out the name of its component, then the function in question, and then some further information. For example:
0041:fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
is printed in the NtLockFile() function, which is part of ntdll. It's printed in the source by a FIXME macro:
dlls/ntdll/file.c:3424: FIXME("I/O completion on lock not implemented yet\n");
In general you can just grep for the function name. I hope this helps.
Also please feel free to ask about any specific FIXME or bug before trying to tackle it. A fair number of features are as yet unimplemented because they're more work than they're worth.
ἔρρωσο, Zeb
Hi and welcome! Please also note that you need to submit a patch to wine prior to the proposal deadline. You should ideally have submitted a patch by the time you've sent in your GSOC application. Your patch must be accepted by March 27 16:00 UTC (student application deadline). Please don't wait until the last minute. As long as your patch does something useful (fixes a bug, adds more tests, pretty much anything more than fixing a comment), you are considered eligible for GSOC. Be free to ask questions here!
So I've gone off to look for some fixmes. I started looking at a game I've tried to run in the past with no success, Fortnite. Do any of the fixmes in the bug report look doable for a persons first patch? Bug page: https://bugs.winehq.org/show_bug.cgi?id=41258 I was looking at the fixmes printed in this output: https://bugs.winehq.org/attachment.cgi?id=55555 On Thu, Mar 15, 2018 at 3:38 PM, André Hentschel <nerv(a)dawncrow.de> wrote:
Am 15.03.2018 um 17:43 schrieb Zebediah Figura:
On 15/03/18 01:38, Kieran Duggan wrote:
Hello, I am a computer science student at the City College of New York. I have used Linux for a few years now and have frequently relied on Wine to run windows applications, so the opportunity to contribute to Wine is exciting to me.
I have successfully built wine from source and ran Ski Free on it to test if it worked. Next I wanted to try and find some of the fixmes that were popping up so I could attempt my first patch, however I am having trouble finding where exactly in the source the fixme's are arising. Maybe It's obvious and I'm just too tired right now to figure it out, but I would be very appreciative if someone could point me in the right direction with this.
While I have been learning computer science for years now, I have not yet contributed to an open source project. I am very eager to learn and become familiar with the process.
Thank you! Kieran Duggan
Hello Kieran, and thanks for your interest in Wine and GSoC!
A fixme: message prints out the name of its component, then the function in question, and then some further information. For example:
0041:fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
is printed in the NtLockFile() function, which is part of ntdll. It's printed in the source by a FIXME macro:
dlls/ntdll/file.c:3424: FIXME("I/O completion on lock not implemented yet\n");
In general you can just grep for the function name. I hope this helps.
Also please feel free to ask about any specific FIXME or bug before trying to tackle it. A fair number of features are as yet unimplemented because they're more work than they're worth.
ἔρρωσο, Zeb
Hi and welcome!
Please also note that you need to submit a patch to wine prior to the proposal deadline. You should ideally have submitted a patch by the time you've sent in your GSOC application. Your patch must be accepted by March 27 16:00 UTC (student application deadline). Please don't wait until the last minute. As long as your patch does something useful (fixes a bug, adds more tests, pretty much anything more than fixing a comment), you are considered eligible for GSOC. Be free to ask questions here!
On 17 March 2018 at 19:06, Kieran Duggan <kieranduggan15(a)gmail.com> wrote:
So I've gone off to look for some fixmes. I started looking at a game I've tried to run in the past with no success, Fortnite. Do any of the fixmes in the bug report look doable for a persons first patch?
In case it helps you or anyone else, we also have a number of issues found by Valgrind [1], most of which should be fairly straightforward to debug and most of which should only have a limited scope. If you're feeling a little more ambitious, I also have lists of Direct3D [2] and D3DX [3] bugs with various levels of analysis I'd love for someone to take a look at. [1] https://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bu... [2] https://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bu... [3] https://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bu...
Yes that is very useful! I took a look at the first one I saw on the list. It goes: ==3551== 8 bytes in 1 blocks are definitely lost in loss record 63 of 766 ==3551== at 0x7BC51061: notify_alloc (heap.c:254) ==3551== by 0x7BC5554F: RtlAllocateHeap (heap.c:1716) ==3551== by 0x5C85281: XAudio2Create (xaudio_dll.c:2159) ==3551== by 0x4A1B741: func_xaudio2 (xaudio2.c:1150) ==3551== by 0x4A1C74F: run_test (test.h:603) ==3551== by 0x4A1CBAD: main (test.h:687) ==3551== To fix it I looked at the XAudio2Create function and noticed that IClassFactory *cf was assigned in the call make_xaudio2_factory(&IID_IClassFactory, (void**)&cf); which contains struct xaudio2_cf *ret = HeapAlloc(GetProcessHeap(), 0, sizeof(struct xaudio2_cf)); Later in the code IClassFactory_Release(cf); is used, but this wouldn't free up the space on the heap because of how that function is implemented. I'm typing this all out because I don't know how good my thought process is on this. I'm not used to it so trying to chase all these function calls around is kind of difficult. I would appreciate any feedback On Sat, Mar 17, 2018 at 12:27 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 17 March 2018 at 19:06, Kieran Duggan <kieranduggan15(a)gmail.com> wrote:
So I've gone off to look for some fixmes. I started looking at a game I've tried to run in the past with no success, Fortnite. Do any of the fixmes in the bug report look doable for a persons first patch?
In case it helps you or anyone else, we also have a number of issues found by Valgrind [1], most of which should be fairly straightforward to debug and most of which should only have a limited scope. If you're feeling a little more ambitious, I also have lists of Direct3D [2] and D3DX [3] bugs with various levels of analysis I'd love for someone to take a look at.
[1] https://bugs.winehq.org/buglist.cgi?bug_status= UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_ status=REOPENED&columnlist=bug_id%2Cshort_desc%2Cbug_ status%2Cresolution&keywords=valgrind&order=bug_id%20DESC [2] https://bugs.winehq.org/buglist.cgi?bug_status= UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_ status=REOPENED&columnlist=bug_id%2Cshort_desc%2Cbug_ status%2Cresolution&component=directx-d3d&keywords=download& order=bug_id%20DESC [3] https://bugs.winehq.org/buglist.cgi?bug_status= UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_ status=REOPENED&columnlist=bug_id%2Cshort_desc%2Cbug_ status%2Cresolution&component=directx-d3dx9&component= directx-d3dx10&keywords=download&order=bug_id%20DESC
On 19 March 2018 at 10:01, Kieran Duggan <kieranduggan15(a)gmail.com> wrote:
Yes that is very useful! I took a look at the first one I saw on the list. It goes:
==3551== 8 bytes in 1 blocks are definitely lost in loss record 63 of 766 ==3551== at 0x7BC51061: notify_alloc (heap.c:254) ==3551== by 0x7BC5554F: RtlAllocateHeap (heap.c:1716) ==3551== by 0x5C85281: XAudio2Create (xaudio_dll.c:2159) ==3551== by 0x4A1B741: func_xaudio2 (xaudio2.c:1150) ==3551== by 0x4A1C74F: run_test (test.h:603) ==3551== by 0x4A1CBAD: main (test.h:687) ==3551==
To fix it I looked at the XAudio2Create function and noticed that IClassFactory *cf was assigned in the call make_xaudio2_factory(&IID_IClassFactory, (void**)&cf); which contains struct xaudio2_cf *ret = HeapAlloc(GetProcessHeap(), 0, sizeof(struct xaudio2_cf));
Later in the code IClassFactory_Release(cf); is used, but this wouldn't free up the space on the heap because of how that function is implemented.
I believe it does. Commit 45babd780f586eb8d0a93205d0998d6ce3f8396d (which was committed after the bug report), changed make_xaudio2_factory() to no longer return class factories with a zero reference count. That happens sometimes. Unfortunately, looking over the first couple of entries in the list, it seems likely most of them are similarly already fixed. If you have the time and inclination it would certainly be useful to go over that list to figure out which ones are already fixed and which ones aren't, but that would make this a bit more of a challenge than I had intended. Sorry about that. Still, bugzilla is not a bad place to look for things to fix. The "download" keyword should limit searches to bugs that can be reproduced with free downloads. We also have various small cleanup tasks like e.g. replacing HeapAlloc() usage with the heap_alloc() helper, or introducing usage of the ARRAY_SIZE macro. The "patches" page [1] and git log may have other examples. [1] https://source.winehq.org/patches/
So I'm trying to run the tests with valgrind to find memory leaks but when I use valgrind I end up getting output looking something like this ==14135== 288 (256 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 166 of 278 ==14135== at 0x442EB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==14135== by 0x96B50B9: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0) ==14135== by 0x96B5829: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0) ==14135== by 0x96B6D4A: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0) ==14135== by 0x96BC19B: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.9.0) ==14135== by 0x98E3A9B: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.6.0) but this isn't nearly as useful as the output I see on bugzilla, which includes function calls and such I tried recompiling my build with valgrind installed on my computer and checked to be sure that the make config was detected it with grep VALGRIND include/config.h and I get #define HAVE_VALGRIND_MEMCHECK_H 1 #define HAVE_VALGRIND_VALGRIND_H 1 so I don't think that is the problem. It seems to me like valgrind is expecting there to be some flags or something for it to find but they aren't there. Can anyone offer some assistance? On Mon, Mar 19, 2018 at 5:51 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 19 March 2018 at 10:01, Kieran Duggan <kieranduggan15(a)gmail.com> wrote:
Yes that is very useful! I took a look at the first one I saw on the list. It goes:
==3551== 8 bytes in 1 blocks are definitely lost in loss record 63 of 766 ==3551== at 0x7BC51061: notify_alloc (heap.c:254) ==3551== by 0x7BC5554F: RtlAllocateHeap (heap.c:1716) ==3551== by 0x5C85281: XAudio2Create (xaudio_dll.c:2159) ==3551== by 0x4A1B741: func_xaudio2 (xaudio2.c:1150) ==3551== by 0x4A1C74F: run_test (test.h:603) ==3551== by 0x4A1CBAD: main (test.h:687) ==3551==
To fix it I looked at the XAudio2Create function and noticed that IClassFactory *cf was assigned in the call make_xaudio2_factory(&IID_IClassFactory, (void**)&cf); which contains struct xaudio2_cf *ret = HeapAlloc(GetProcessHeap(), 0, sizeof(struct xaudio2_cf));
Later in the code IClassFactory_Release(cf); is used, but this wouldn't free up the space on the heap because of how that function is implemented.
I believe it does. Commit 45babd780f586eb8d0a93205d0998d6ce3f8396d (which was committed after the bug report), changed make_xaudio2_factory() to no longer return class factories with a zero reference count. That happens sometimes.
Unfortunately, looking over the first couple of entries in the list, it seems likely most of them are similarly already fixed. If you have the time and inclination it would certainly be useful to go over that list to figure out which ones are already fixed and which ones aren't, but that would make this a bit more of a challenge than I had intended. Sorry about that.
Still, bugzilla is not a bad place to look for things to fix. The "download" keyword should limit searches to bugs that can be reproduced with free downloads. We also have various small cleanup tasks like e.g. replacing HeapAlloc() usage with the heap_alloc() helper, or introducing usage of the ARRAY_SIZE macro. The "patches" page [1] and git log may have other examples.
participants (4)
-
André Hentschel -
Henri Verbeet -
Kieran Duggan -
Zebediah Figura