(was writing this response when you asked about local file system, see below, I think we are converging on an explanation)
Found another way to reliability reproduce this, I saved a core file with gdb when it occurs (beta 3, linux x64), and I also have a theory as to what is going on.
My other method of reproducing is to have "Date Modified" column enabled when I start SE and before I load my workspace.
Open my workspace, there is no freeze.
Type 1 character into the smart open edit box, and then SE freezes.
I attached with gdb and generated a core file, see: mainfreeze.7z at
https://drive.google.com/file/d/0B7AlniF_4GyYSDBRNmRJOTFlMnM/view?usp=sharingAs I wrote about in another post -
https://community.slickedit.com/index.php/topic,15553.msg59190.html#msg59190 :
I work in a Linux NIS/Clearcase environment. Certain directories (example: /vobs) take a very long time to list all the files. For example, if I type "/vobs" into smart open, SE freezes for a very long time while it tries to get a listing of all the files in /vobs. The same thing happens when I do "ls /vobs" at the command line. Even if I want to go to the directory /vobs/dir1/dir2, SE is frozen after /vobs for a long time, hurting productivity, even though I don't need a listing of the files there. My workaround is to usually type a junk character first, like s/vobs/dir1/dir2, then remove the "s".
So my theory as to what is happening is when I type 1 character into smart open edit box, SE is trying to scan the modification times of all the files, and as my source files are on the networked/slow clearcase file system, SE is doing all this scanning for modification times in the main thread and is freezing. I think I observed once if I waited long enough the freeze goes away. I also looked at the stack of the core file I sent and SE seems to be waiting to get a modification time:
(gdb) info stack
#0 0x00007fc1f6494eb5 in _lxstat () at /lib64/libc.so.6
#1 0x0000000001a52b04 in cmFindFile_Posix::statInfoToFindFileInfo(cmStringT<char, 1, 30> const&, cmStringT<char, 1, 30> const&, cmFindFileInfo&) ()
#2 0x0000000001a52d22 in cmFindFile_Posix::findFirst(cmStringT<char, 1, 30> const&, cmFindFileInfo&, cmFindFileFlags, long long) ()
#3 0x00000000018b7eb1 in cmFile::getFindFileInfo(cmStringT<char, 1, 30> const&, cmFindFileInfo&, cmFindFileFlags) ()
#4 0x00000000008d9fc9 in getInfoForCaption(cmStringT<char, 1, 30>, FLMFileInfo*) ()
One thing that may help, it seems to be mostly the "/vobs" directory that is slow to enumerate. But if I have a file in /vobs/dir1/dir2, that subdirectory is not slow (for example when I do "ls" at the prompt). So I wonder if SE is doing a scan of each directory in the chain? If so then the first scan of /vobs could cause the freezing for a while? Perhaps only scan the files that show up in the wildcard search, and not their parent directories?