>> I can confirm that this crash is also reproducible with the latest
>> nightly build of TSVN
>
> thanks for looking into it Tobias! we get the same crash at the exact same
> location
>
>> "Unhandled exception at 0x7c9fb06f in xplorer2_UC.exe: 0xC0000005: Access
>> violation reading location 0x01840044."
>
> this address is a bit weird but could be down to the "funny" way OLE
> exposes dataobjects to different threads
>
>> Stacktrace:
>> TortoiseSVN.dll!ItemIDList::toString() Line 95 + 0x22 bytes C++
>> TortoiseSVN.dll!CShellExt::Initialize(const _ITEMIDLIST *
>> pIDFolder=0x00000000, IDataObject * pDataObj=0x00cee310, HKEY__ *
>> __formal=0x0000025e) Line 162 + 0x12 bytes C++
>>
>> Abviously parent_ is not null but not valid either. The same also applies
>> to the variable item_ in line 106. It is also not null but not valid.
>
> I don't have access to the source code (I don't want to either :), but I
> return the IDList requested as such within the medium:
>
> HGLOBAL hMem = GlobalAlloc(GMEM_SHARE | GMEM_MOVEABLE, m_uTotalSize);
> LPVOID pv = GlobalLock(hMem);
> memcpy(pv, m_pCIDA, m_uTotalSize);
> GlobalUnlock(hMem);
> pmedium->hGlobal = hMem;
> pmedium->tymed = TYMED_HGLOBAL;
>
> could tortoise be doing any assumptions about movable memory? are you
> locking the memory before access?
No. TSVN doesn't require movable memory.
But you really should check the return values of GlobalLock() and
GlobalAlloc() before you try using that memory.
> also note that the way x2 prepares the CIDA for multiple folders is such
> that the "root" is the common folder and as such not necessarily the
> desktop, e.g if you had 2 items like:
>
> c:\temp\a.txt
> c:\temp\folder\b.cpp
>
> the root folder would be "c:\temp" and the 2 items will be stored as
> "a.txt" and "folder\b.cpp" (of course as pidls). But if you use the
> following macros to access the items and you merge the root with each one
> you shouldn't have any problems:
>
> #define HIDA_GetPIDLFolder(pida)
> (LPCITEMIDLIST)(((LPBYTE)pida)+(pida)->aoffset[0])
> #define HIDA_GetPIDLItem(pida, i)
> (LPCITEMIDLIST)(((LPBYTE)pida)+(pida)->aoffset[i+1])
We already use those defines (different define name, but the rest is the
same).
The problem is that many programs need a full path (or try to find that
full path) of a PIDL with something like this:
hr = ::SHGetMalloc(&pMalloc);
hr = ::SHGetDesktopFolder(&shellFolder);
if (parent_)
{
hr = shellFolder->BindToObject(parent_, 0, IID_IShellFolder, (void**)
&parentFolder);
if (!SUCCEEDED(hr))
parentFolder = shellFolder;
}
else
{
parentFolder = shellFolder;
}
> could tortoise assume that the root in the cida would be the desktop and
> each item below would be a full pidl?
Exactly. The Desktop is the shell namespace root and therefore *always*
exists. Many functions have to use that root because of that. At least
all functions that need a full path as the result and not just a
filename. In your case, the property pages in the default explorer
'properties' dialog only act on files/folders and don't need the full
path (or don't need those if multiple items are selected). TSVN needs
the full path even if multiple items are selected, so it's important
that the PIDL root is the desktop.
In the above code snippet, the crash occurs inside the BindToObject()
call because the root is not the desktop.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed May 10 19:18:10 2006