I have a certain working copy where tortoiseSVN hangs sometimes when I try to commit or execute a check for modification (didn't try all svn commands, so other might fail as well). This repository is a little different than the other repositories I'm working with. This repository contains mainly binary fails, varying in size from a couple of KB to a couple of MB.
To reproduce the problem I click right on a certain file in the working copy and click on commit. The commit dialog appears and will not show the file to commit. After a couple of seconds it says "not responding". I had the dialog in this state for more then half an hour, but nothing changes. During this time, the corresponding TortoiseProc.exe takes about 13% of the CPU (on Core i7 860).
I tried to run a clean up on the root of the working copy. This didn't help to solve the problem. After I restarted my computer, I was able to commit a couple of files (3 commits this time, with a different number of files). After those commits, it failed again and the commit dialog hangs.
To see what is the problem, I recorded a successful commit dialog (on a different repository) and the failing commit dialog with DebugView. Attached are both log files.
We had this problem once before. Back then SVN 1.7 was just released. A colleague worked with SVN 1.7 and wasn't able to commit. I was still using SVN version 1.6 at the time and copied his files in my working copy. I was then able to commit them. We didn't investigate the problem any further back then. We do have another repository with mainly binary files. We use that repository far more often then the repository that gives us trouble now. We never encountered problems of this kind in that repository.
Has anybody any idea what can cause this, or how I can further investigate what the problem is?
My system:
Windows 7 professional 64bit (Dutch)
TortoiseSVN 1.7.10, Build 23359 - 64 Bit , 2012/10/08 11:46:26
If any additional information can help, please ask.
> I have a certain working copy where tortoiseSVN hangs sometimes when I try to commit or execute a check for modification (didn't try all svn commands, so other might fail as well). This repository is a little different than the other repositories I'm working with. This repository contains mainly binary fails, varying in size from a couple of KB to a couple of MB.
> To reproduce the problem I click right on a certain file in the working copy and click on commit. The commit dialog appears and will not show the file to commit. After a couple of seconds it says "not responding". I had the dialog in this state for more then half an hour, but nothing changes. During this time, the corresponding TortoiseProc.exe takes about 13% of the CPU (on Core i7 860).
> I tried to run a clean up on the root of the working copy. This didn't help to solve the problem. After I restarted my computer, I was able to commit a couple of files (3 commits this time, with a different number of files). After those commits, it failed again and the commit dialog hangs.
> To see what is the problem, I recorded a successful commit dialog (on a different repository) and the failing commit dialog with DebugView. Attached are both log files.
> We had this problem once before. Back then SVN 1.7 was just released. A colleague worked with SVN 1.7 and wasn't able to commit. I was still using SVN version 1.6 at the time and copied his files in my working copy. I was then able to commit them. We didn't investigate the problem any further back then. We do have another repository with mainly binary files. We use that repository far more often then the repository that gives us trouble now. We never encountered problems of this kind in that repository.
> Has anybody any idea what can cause this, or how I can further investigate what the problem is?
> My system:
> Windows 7 professional 64bit (Dutch)
> TortoiseSVN 1.7.10, Build 23359 - 64 Bit , 2012/10/08 11:46:26
> If any additional information can help, please ask.
The log files don't really show why it hangs.
But try this:
Settings dialog->dialogs 2->Commit->use auto-completion...
uncheck that setting and try again.
run
procdump -e -h -ma -w tortoiseproc
then start the commit dialog.
As soon as it hangs ("not responding") a dump file is written. Send me that dump please.
Stefan
-- ___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
I noticed some other aspects when it failed and when not. I don't know if it is useful information, so I report it here anyway.
Today, the first time I was able to get the commit dialog normally. I didn't make a commit, just clicked the dialog away. I did a "check for modification", it was successful. I did an update, which was successful (no changes to the working copy, I was already up to date with head). Then I did a commit again, which hang again.
I did all these steps to the root of my working copy, which is a check out of the root of the repository.
I then changed one of the tortoisesvn settings. (I can't recall exactly which, but it was the 'Debug' or the 'DebugOutputString', I turned them both on and off today). After changing those settings, and without doing anything else (so I didn't do a PC restart or a 'clean up') on a commit, the commit dialog appeared again.
I did some 'check for modifications' and updates, and then the commit dialog hang.
At that point I started the commit with procdump. I have the log file, I won't send it to the list, because of the size, I will send it to you personally Stefan.
> I tried to turn off:
>> Settings dialog->dialogs 2->Commit->use auto-completion...
> I was still able to let the commit log fail.
> I noticed some other aspects when it failed and when not. I don't
> know if it is useful information, so I report it here anyway.
> Today, the first time I was able to get the commit dialog normally. I
> didn't make a commit, just clicked the dialog away. I did a "check
> for modification", it was successful. I did an update, which was
> successful (no changes to the working copy, I was already up to date
> with head). Then I did a commit again, which hang again. I did all
> these steps to the root of my working copy, which is a check out of
> the root of the repository.
> I then changed one of the tortoisesvn settings. (I can't recall
> exactly which, but it was the 'Debug' or the 'DebugOutputString', I
> turned them both on and off today). After changing those settings,
> and without doing anything else (so I didn't do a PC restart or a
> 'clean up') on a commit, the commit dialog appeared again.
> I did some 'check for modifications' and updates, and then the commit
> dialog hang.
> At that point I started the commit with procdump. I have the log
> file, I won't send it to the list, because of the size, I will send
> it to you personally Stefan.
I've analyzed the process dump you sent me. Here's what I found:
The commit dialog (and various other dialogs in TSVN) show file icons for list entries. In the commit dialog, you see a txt icon for text files, html icon for html files and so forth. The same happens in the repository browser.
you can see that if the flag SHGFI_USEFILEATTRIBUTES is specified, " the function should not attempt to access the file specified by pszPath". That's because e.g. in the repo browser, the files are not physically available. They mostly are in the commit dialog, but the commit dialog also shows missing and deleted files as well, and those files are not available either.
And TSVN does not pass full paths to this API anyway since it's not necessary if the flag SHGFI_USEFILEATTRIBUTES is specified. So it would be very, very rare that an icon handler could even find the file at all.
Now what's happening on your machine is that you've got an icon handler installed that should return the icon of such a file. But it's faulty in that it doesn't handle situations where the file isn't available and then simply hangs/blocks. Not sure if it always blocks under these circumstances, but it blocks in the process dump you've sent me.
The icon handler is inside the sldwinshellextu.dll which is according to web search from SolidWorks.
> I tried to turn off:
>> Settings dialog->dialogs 2->Commit->use auto-completion...
> I was still able to let the commit log fail.
> I noticed some other aspects when it failed and when not. I don't
> know if it is useful information, so I report it here anyway.
> Today, the first time I was able to get the commit dialog normally. I
> didn't make a commit, just clicked the dialog away. I did a "check
> for modification", it was successful. I did an update, which was
> successful (no changes to the working copy, I was already up to date
> with head). Then I did a commit again, which hang again. I did all
> these steps to the root of my working copy, which is a check out of
> the root of the repository.
> I then changed one of the tortoisesvn settings. (I can't recall
> exactly which, but it was the 'Debug' or the 'DebugOutputString', I
> turned them both on and off today). After changing those settings,
> and without doing anything else (so I didn't do a PC restart or a
> 'clean up') on a commit, the commit dialog appeared again.
> I did some 'check for modifications' and updates, and then the commit
> dialog hang.
> At that point I started the commit with procdump. I have the log
> file, I won't send it to the list, because of the size, I will send
> it to you personally Stefan.
I've analyzed the process dump you sent me. Here's what I found:
The commit dialog (and various other dialogs in TSVN) show file icons for list entries. In the commit dialog, you see a txt icon for text files, html icon for html files and so forth. The same happens in the repository browser.
you can see that if the flag SHGFI_USEFILEATTRIBUTES is specified, " the function should not attempt to access the file specified by pszPath". That's because e.g. in the repo browser, the files are not physically available. They mostly are in the commit dialog, but the commit dialog also shows missing and deleted files as well, and those files are not available either.
And TSVN does not pass full paths to this API anyway since it's not necessary if the flag SHGFI_USEFILEATTRIBUTES is specified. So it would be very, very rare that an icon handler could even find the file at all.
Now what's happening on your machine is that you've got an icon handler installed that should return the icon of such a file. But it's faulty in that it doesn't handle situations where the file isn't available and then simply hangs/blocks. Not sure if it always blocks under these circumstances, but it blocks in the process dump you've sent me.
The icon handler is inside the sldwinshellextu.dll which is according to web search from SolidWorks.
