SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: texasaggie97 on March 17, 2021, 02:42:02 PM
-
I am on Windows using SlickEdit Pro 2020 (v25.0.1.0 64-bit)
SlickEdit will crash completely. Any unsaved changes are lost, and when I reload, it takes one of the open files and opens it N number of times based on how many windows were open when it crashed, and they are labeled filename:1, filename:2, etc.
This has happened a couple of times over the last couple of weeks. I don't know what I was doing the other times, but this time I was switching open tabs using the mouse. I cannot find a dump file or anything like that. When it crashes it is just gone, with no notification.
I realize this isn't much to go on for debugging so is there some setting I can turn on to try to get more information if it happens again?
-
I had a crash like that a couple of days ago when I was playing with floating edit windows. Do you have any floating edit windows?
If you haven't already you might want to turn on "auto save after period of time" - I have it set to ten seconds. Also have backup history on so you can easily revert and see what has been changed etc. Also turn on "save files on loss of focus".
-
Have a look in the windows system event viewer and see if you're getting application error 1000, exception code 0xC0000005. I have three of these from slickedit and three from other apps - onenote, explorer, searchapp.exe.
Slick has two from vsapi.dll (same fault offset), one from cparse.dll.
-
If you have Visual Studio installed, and you're not getting a prompt to debug on crash (which would allow you to create a minidump), probably the easiest thing to do is to change the window error reporting so it automatically creates minidumps for crashing processes. It does require you to add/change registry settings. The instructions are here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx
You would want a minidump, so DumpType=1 in those instructions. Let us know if you get a minidump on the crash, and we'll send instructions on how to get it to us so we can look at it.
-
I have vstudio installed - community edition. When slick crashed it just disappeared - no windows dialog, no access violation error reported. Where would the minidump file be if it exists.
-
I've got yet another access violation - this time in qtcore dll. I got a minidump from the debugger. The call stack seemed kind of deep, like maybe overflowing. Three different access violations now... also I'm getting a slick stack with one of my own macros (not published) - can a problem in my macro code cause an access violation ?? It's not uncommon for me to get a slick stack in this particular macro when I'm doing something unusual - I'm too lazy to debug it, I just restart the editor and carry on.
-
I'll PM you with upload instructions for the minidump(s).
We don't know of any Slick-C stacks that would cause a crash. You can send the stack traces along with the minidumps if you like. Just let us know if you're running the published version of your macros, or something else you'd need to send to us.
-
It just happened again and I see this in the System event viewer. I do have Visual Studio installed and it did not prompt me for anything. I will follow those instruction to enable the minidump at the system level.
-
I got a minidump of a crash. How would you like me to upload it to you? I am running with no macro modifications.
SlickEdit Pro 2020 (v25.0.1.0 64-bit)
Serial number: WB945742
Licensed number of users: Single user
License file: C:\ProgramData\slickedit\25\slickedit.lic
Build Date: December 16, 2020 (State file: February 12, 2021)
Emulation: CUA
OS: Windows 10 x64
OS Version: 10.00.0
Memory: 29% Load, 19638MB/65488MB Physical, 24713MB/183007MB Page File, 9054MB/134217727MB Virtual
Shell Information: C:\Windows\system32\cmd.exe /q
Screen Size: 2560 x 1440 (0 0 2560 1440), 2560 x 1440 (2560 0 2560 1440)
Project Type: Python
Language: No file open
Encoding: No file open
Installation Directory: C:\Program Files\SlickEdit Pro 25\ (non-removable drive,NTFS,330160MB free)
Configuration Directory: C:\Users\msilva\Documents\My SlickEdit Config\25.0.1\ (non-removable drive,NTFS,330160MB free)
Migrated from: C:\Users\msilva\Documents\My SlickEdit Config\25.0.0\
Spill File: C:\Users\msilva\AppData\Local\Temp\$slk.31728 (non-removable drive,NTFS,330160MB free)
Hotfixes:
C:\Users\msilva\Documents\My SlickEdit Config\25.0.1\hotfixes\hotfix_se2501_2_cumulative.zip (Revision: 2)
-
PM sent texasaggie97.
Regards,
SlickEdit Support
-
I had three so I uploaded all of them for your debugging pleasure... I hope they are able to help. Is there any other information that may help?
-
Nothing we need right now. I'd suggest that the next time you're not running SlickEdit to go in and delete any of your project's tag files, for the projects you had open when it crashed. The tag files will be regenerated the next time you open the projects, so you don't lose anything.
The tagging has consistency checking that can usually detect when a crash has caused an incomplete write of a tag file, but easier to not risk it causing any additional problems that could interfere with troubleshooting.
-
The dumps narrow it down, but still trying to track down what's leading up to the crash. Something is happening while files are being iterated for tagging, but it's not clear whether it's the contents of a file or something about the configuration that's the cause.
Could you upload your user.cfg.xml file from your configuration file to the same place you put the dumps? The default configuration directory for your version would be My Documents\My SlickEdit Config\25.0.1, but you can check the output of Help About to find the exact location if there's any question.
The other thing that might help is the files that are being tagged. Is this source you could upload to us? If not, it might help zip up just the project files (*.vpj, *.vpw, *.vpwhist) and upload those.
-
I uploaded both the user.cfg.xml and a zip with the *.vpw, *,vpwhist and the *.vpj's.
One of the git repos pointed to by one of the vpj files is large. It is currently ~16GB in size in ~311k files with a mix of files: C/C++, C#, perl, python, LabVIEW files, documentation files, etc.
-
Thanks, we got the files.
-
This one is odd. It does seem to be hitting the same thing for all your crashes, possibly for the same file. We can tell it's happening while tagging a perl file, but the places where we could extract an actual file name are either overwritten, or not included in the minidump.
For the perl files in your projects, do any of them use the feature where you can tag a HERE doc with the language type so the string will be color coded as that language?
For example, the $mess string here would be color coded as Ruby script:
my $mess = <<'ruby';
def find_missing(sequence)
consecutive = sequence.each_cons(2)
end
ruby
If any of your perl scripts are using that, what languages are they embedding in the HERE docs?