Hello all,
It's a well-known fact that our wiki sucks and is out of date. I've been making at least some effort to try to improve that. Not much, but...
In particular I've just done some lengthy expansion to the "debugging hints" page: https://wiki.winehq.org/Debugging_Hints
As a new Wine developer I remember being frustrated by how difficult it is to debug things. To a certain degree I still am, sometimes. While being good at debugging applications in Wine really is a matter of experience more than anything else, I do think there are some things that can be taught, at least as a starting point. To that end I've tried to sort of document my process of debugging, and as many specific tips as I can think of, at that page.
This mail, then, is a call to help that. There are plenty of people around who are far more experienced than me, so I'd really appreciate any further tips that they can add to the page. Similarly, any blatant misinformation that I've put in there would be best corrected immediately.
ἔρρωσθε, Zeb
On Mon, 17 Jun 2019 18:58:22 -0500 Zebediah Figura z.figura12@gmail.com wrote:
Hello all,
It's a well-known fact that our wiki sucks and is out of date. I've been making at least some effort to try to improve that. Not much, but...
In particular I've just done some lengthy expansion to the "debugging hints" page: https://wiki.winehq.org/Debugging_Hints
As a new Wine developer I remember being frustrated by how difficult it is to debug things. To a certain degree I still am, sometimes. While being good at debugging applications in Wine really is a matter of experience more than anything else, I do think there are some things that can be taught, at least as a starting point. To that end I've tried to sort of document my process of debugging, and as many specific tips as I can think of, at that page.
This mail, then, is a call to help that. There are plenty of people around who are far more experienced than me, so I'd really appreciate any further tips that they can add to the page. Similarly, any blatant misinformation that I've put in there would be best corrected immediately.
ἔρρωσθε, Zeb
Thanks a lot for putting the time and effort into that! It seems very useful indeed.
I was reading the article on Performance [1] just the other day, which did leave me wanting for more. Previously I've also read the Debugging Wine [2] article a few times at least, but it seems a bunch have been added there, too, since I last did so (years ago, probably, before the new wikki set-up).
I had this issue with Final Fantasy XIV, that apparently no one else did, which already should have pointed me towards doing a (really) clean install of it. Thing is, I was re-using the old data files, because they're kind of big (25'ish GiBs), and I'd assumed a little that the update check actually verifies the files, and re-downloads them if need be...
I noticed the trial client worked just fine, so as a next thing I fed the data files to 'md5sum' and compared them... they were indeed different. Granted, the trial and retail might have used different files even to that extent, but mayhap that was unlikely, and so I tried the trial big files with the retail client and it would work again as well!
I think last that game was running for me, was back in 2017 (I don't actively play it), so it was quite fun to see it work once more again.
And it wasn't even an issue with Wine in the end! Did not see that one coming.
Had I known the meaning of 'c0000005' before, it might have made things faster (I did end up reading about it in Debug Channels [3], after I had already resolved the issue).
1. https://wiki.winehq.org/Performance 2. https://wiki.winehq.org/Wine_Developer%27s_Guide/Debugging_Wine 3. https://wiki.winehq.org/Debug_Channels
With +relay logs I've often found it useful to delete lines that I'm reasonably sure are not relevant. In Vim, the :g/pattern/d command will delete all matching lines, for example :g/ntdll.RtlHeap/d will remove heap-related calls. This has a side-effect of moving your cursor, so it's important to keep a bookmark you can return to afterwards.
(I'd add that to the wiki, but I just created my account, and it can't make edits.)
It may also be useful for novice debuggers to mention any classes of problems that are not covered on the page. That may jog the memories of those with more experience.
On Tue, Jun 18, 2019 at 09:54:42AM -0500, Vincent Povirk (they/them) wrote:
With +relay logs I've often found it useful to delete lines that I'm reasonably sure are not relevant. In Vim, the :g/pattern/d command will delete all matching lines, for example :g/ntdll.RtlHeap/d will remove heap-related calls. This has a side-effect of moving your cursor, so it's important to keep a bookmark you can return to afterwards.
I have a similar script that does this with grep:
https://gitlab.com/mywinetools/mywinetools/blob/master/filter_junk
Andrew
On Tue, 18 Jun 2019 09:54:42 -0500 "Vincent Povirk (they/them)" vincent@codeweavers.com wrote:
(I'd add that to the wiki, but I just created my account, and it can't make edits.)
Tell me your username and I'll give you edit privileges.
On Dienstag, 18. Juni 2019 16:54:42 CEST Vincent Povirk (they/them) wrote:
With +relay logs I've often found it useful to delete lines that I'm reasonably sure are not relevant. In Vim, the :g/pattern/d command will delete all matching lines, for example :g/ntdll.RtlHeap/d will remove heap-related calls.
Isn't that what +relay exclusions are for? Those set in the registry, I mean. Although I have to admit they never worked too well for me...
Regards, Fabian Maurer
On 6/18/19 11:23 AM, Fabian Maurer wrote:
On Dienstag, 18. Juni 2019 16:54:42 CEST Vincent Povirk (they/them) wrote:
With +relay logs I've often found it useful to delete lines that I'm reasonably sure are not relevant. In Vim, the :g/pattern/d command will delete all matching lines, for example :g/ntdll.RtlHeap/d will remove heap-related calls.
Isn't that what +relay exclusions are for? Those set in the registry, I mean. Although I have to admit they never worked too well for me...
Sure. But relay exclusions are often inconvenient (e.g. you have to reset them for each new prefix, and editing the registry is not literally the easiest way to do things), and often you'll want to cull +relay logs for very specific cases.