Win64 V17 Hang.

[jporkkahtc]

2 hangs today.
1st was (I think) when I tried a symbol lookup.
The 2nd, I don't know but I think it was when I was starting a clipboard operation.

I have dump files if you need them.

[Matthew]

From the looks of these you have a couple tag files that are still mid-stream and are never fully completing.

Tagging related hangs usually are a result of one of the following
- Rebuilding the file too often, such as those triggered by app activate/deactivate events
- Tagging stalls when encountering a source file that confuses the tagging parser. Rare, but we have seen this before.

 If you are seeing this on a constant basis, I recommend the following:
1. Rebuild your compiler/framework global tag files from the Tools > Tag Files menu. Use the AutoTag button to select which ones to rebuild and de-select the background tagging option. That will force those tag files to complete in the foreground. May take a little while but you'll be assured of a clean & complete file.

2. Check your settings for background tagging. (Tools > Options, in the Editing > Context Tagging section) I usually recommend turning off the "Update Workspace Tag file on Activate" setting, and also turning off "Background tagging of other files". Once that's done, force a retag of your current via Project > Retag Workspace..., and uncheck the background option in the pop-up dialog.

With those "forced foreground rebuilds" it will be easy to detect if there are any problematic source files that is causing the tagging to stall.

[Dennis]

Hang 1 looks like there was a drag/drop involved.
Hang 2 does involve a clipboard operation.

Did you try interrupting the Slick-C interpreter?
Ctrl+Alt+Shift+F2 or Ctrl+Alt+Shift+F9 if F2 doesn't work.

Since the main thread does not have tagsdb.dll anywhere on it's execution stack, in either case, I'm less inclined to think this hang is on account of background tagging, however, these text stack dumps are very inaccurate, it would be much better to have a minidump to investigate.

I am also surprised by the number of threads reported.

[jporkkahtc]

I've uploaded two dumps that coorespond with the stacks I attached earlier.

[jporkkahtc]

I've uploaded a 3rd ZIP with stack+dump.

In all three cases CAS+F2/F9 has no effect.

In the third case I deleted all *.vtg *.vpw *.vpwhist *.vtg *.vpj files, then ran slick again.

First, it complained
    Workspace 'C:\....\BLAH.vpw' is not recognized as valid and can't be converted.
But, "BLAH.vpw" was created when I had previously opened the VS2008 solution BLAH.sln.

Once I opened BLAH.sln, it rebuilt everything and seemed happy for a few hours, until now when it hung again when I switched back to it from some other application.

[Dennis]

OK, I have thoroughly investigated all three of the dump files.

#1 and #3 appear to be due to a Qt bug related to OLE drag and drop handling, however, I can't explain why you are just getting a hang rather than a crash, but this could be OS differences.  I bet it would crash on XP.
https://bugreports.qt-project.org/browse/QTBUG-13237

#2 is clipboard related.  I have a fix, but since I'm unable to replicate the hang, we are going to have to put the fix out there for 17.0.1 and just hope that it clears things up.

I am not sure why these problems are prevailing on your machine and not effecting a large number of other users.  Are you using a clipboard management tool or something that would tinker frequently with the clipboard and bring clipboard ownership issues to the forefront, or do you switch applications and/or use drag and drop very frequently?

Thank you again for reporting these issues and providing the dump files so that we could try to get to the bottom of these issues.

[Phil Barila]

I've had v17 x64 on Win 7 live-lock on me a time or two, but I was in enough of a hurry that I just whacked it and kept going.  Sorry I didn't capture a process dump.  If it happens again, I'll get a dump and push it up on the support site.  I did observe in Process Explorer before I terminated it that it was fully using two CPU cores.  One of the threads was the GUI thread, don't know the other one.  I think in both cases, I opened a VS 2010 solution and walked away to a meeting, and when I came back and unlocked my workstation, it was stuck.

[jporkkahtc]

I've got a 4th hang, also uploaded.

I was searching in a very large file.
As usual, CAS-F2/F9 had no effect.

I started another instance (with vs +new) to continue working and allow the first instance some time to think things through - maybe it was just going to wait for a long time?
Soon, the 2nd instance hung when I attempted to open a new file (with the WIndows file open dialog).

So, I attached a debugger to the first instance and wrote my dump file.
As soon as the first instance was terminated, the 2nd instance unlocked - almost as if the 2nd instance was waiting on something the first instance was holding.
From procmon this is was I saw:
172   14096   13628   2:09:29.4357577 PM   vs.exe   Process Exit      SUCCESS   Exit Status: 0, User Time: 146.4069385 seconds, Kernel Time: 36.3794332 seconds, Private Bytes: 229,457,920, Peak Private Bytes: 254,844,928, Working Set: 383,315,968, Peak Working Set: 406,142,976
173   14264   10840   2:09:29.4750133 PM   vs.exe   Thread Create      SUCCESS   Thread ID: 10124
Presumably the new thread (and the bunch of activity just after) has something to do with the WIndows file open dialog.



WRT #1 and #3: I *never* intentionally drag-n-drop text. I usually disable that feature, but I've not got around to it since installing the new slick edit.
I can believe all 3 are clipboard related.

#4 appears to have more to do with the Windows file open dialog.
I think that I had just copied a line of text (containing a file path), then attempted to open the file-open dialog. I intended to paste the filename there to open the file.
But, the dialog never appeared.

[Lee]

What source control are you using and are you using Visual Studio solutions/projects?  We've been looking at your dump files and haven't been able reproduce the same problems here.  If you are using Visual Studio projects, it would be a huge help if we could take a look at those project files.

[jporkkahtc]

Source control: Custom command line.
Visual Studio: I'll try to get those uploaded. They are CMake generated.
I also submitted a support case due to frequent hangs:  CAS-58821-B7QQ