SlickEdit Community
Archived Beta Discussions => SlickEdit 201x Beta Discussions => SlickEdit 2016 v21 Beta Discussion => Topic started by: mklein on September 28, 2016, 05:28:45 PM
-
I've gotten into some situation where RC3 is crashing immediately on startup. This is on Ubuntu 16.
I'm trying to figure out how to get the actual crash dump from the Ubuntu shell error reporter (I just see .crash files which don't appear to be normal core dumps).
Let me know how to get you more info.
-
If it's an apport crash file, we can deal with those. They're sort of an archive that contains some system information, some information extracted from the core file, and the actual core file as well. (so they tend to be pretty large like core files). Usually those are stored in /var/crash
gzip up the crash file, and go to http://support.slickedit.com, and upload it there, with 14085 as the case number. And post to let us know when you've done it.
-
Done. I will try deleting my project tag file now to see if I can startup. I was able to see the stack trace (but not copy paste, sigh) and it looks to be in tagging code.
-
FWIW, deleting the project tag file allowed me to start up.
-
Ok, I'm taking a look at it. At first glance, it looks to me like it isn't specific to v21, but has to do with the lexer choking on a particular Javascript file. What probably happened is the first crash that this dump is for corrupted the tagfile, and after that you couldn't startup. Also means that a re-tag might cause it to fall over again. Or not, it's also possible the bug was triggered by an incomplete statement that was still being typed.
Thanks for the dump, I'm looking into it.
-
I was typing when it crashed the first time.
-
Hmm. Any idea what sort of statement or construct you were typing when it crashed?
-
IIRC I was in a Makefile
-
I just got another crash while I was typing. Not sure if this is same issue or different issue, but I uploaded the new dump.
-
Ok, I'll take a look. Thanks for uploading it.
-
That one was a known RC3 problem, that should be fixed for RC4.
For your first crash, I suspect it was caused one of the issues in RC3, but I can't prove it. The code at the crash site is correct, but the data it was being fed was not. If this happens again for you in RC4, we'll probably have to resort to sending you a debug version of the executable to work out what's going on.