Hi,
(please ignore the other copy I sent from the wrong address by accident)
I'm working on a bug in winex11drv/xdnd.c, where file:/// URIs are not correctly interpreted, resulting in DnD broken most of the time. There are two parts of that bug:
1) X11DRV_XDND_BuildDropFiles() fails to properly handle absolute unix paths, which is exactly what you get from file:///, so it won't find the file unless $PWD and the constructed Windows drive-absolute path happen to have the same root. For example, file:///home/mathrick/foo.txt will yield "\home\mathrick\foo.txt" and work only if the current directory is on a drive letter on which that path is valid.
2) X11DRV_XDND_DeconstructTextPlain() fails to accommodate for the fact file:/// URIs are, in fact, URIs and not paths, and doesn't check for validity nor does it unescape % sequences. The result is that paths with spaces, etc. in them won't work.
The attached patch is my first take at 1), it works, but there is a problem. My test application is μTorrent, and it'll randomly lock up with the following errors printed:
err:ntdll:RtlpWaitForCriticalSection section 0x110020 "heap.c: main process heap section" wait timed out in thread 001f, blocked by 0019, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x110020 "heap.c: main process heap section" wait timed out in thread 001e, blocked by 0019, retrying (60 sec)
I can reproduce them by attempting to drop a file on µT's window right after startup. If I wait a while, it works. It also happens if I switch to another virtual desktop, then back to the one µT is on and then try to drop.
I tried to check the code as well as I could (win32 API is not exactly my everyday environment), and I believe it's correct. At least all the allocations appear to be correct, nothing is overwritten. I've tried debugging in several ways using winedbg, but it fails pretty hard with various exceptions that aren't there when running outside the debugger, or fails to attach to the process, etc. From the circumstances, I believe there's some kind of race condition in allocation from process heap. However, I'm unable to find it as I have no idea about wine internals and how exactly DnD happens, and what threads do what and when. I'd be therefore very grateful if someone knowledgeable would take a look at it and see what's wrong, or at least help me with debugging the issue, as my ideas how to attack it have run out.
Cheers,