x11drv: XDND: Fix file drop to properly support file:/// URIs (debugging problem)

[Maciej Katafiasz]

Hi,

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,

-- 
Maciej Katafiasz <email(a)mathrick.org>