Segmentation Fault when adding Git repo on Repository Browser

[Juan Fonseca]

SlickEdit crashes and generates a Segmentation fault every time I try to add a Git repository through the Repository Browser.
I can see this issue on Beta 3 as well. Other Git operations like "History for <file>" and "Compare Directory with git" work properly.

SlickEdit Pro 2018 (v23.0.0.5 64-bit)

Serial number: FE15384_BETA
License type: Beta License
License expiration: 2018-10-09 20:00:00
License file: /home/vagrant/slickedit-pro2018beta4/bin/slickedit.lic

Build Date: September 06, 2018
Emulation: CUA

OS: Linux
OS Version: Linux Mint 17.3 Rosa
Kernel Level: 3.19.0-32-generic
Build Version: #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40 UTC 2015
Processor Architecture: x86_64

X Server Vendor: The X.Org Foundation
Memory: 91% Load, 10284MB/11198MB Virtual
Shell Information: /home/vagrant/slickedit-pro2018beta4/bin/secsh -i
Screen Size: 1920 x 986, 1920 x 1016

Project Type: Gnuc
Language: .cpp (C/C++)
Encoding: Automatic

Installation Directory: /home/vagrant/slickedit-pro2018beta4/
Configuration Directory: /home/vagrant/.slickedit/23.0.0/

[Dan]

Is it a local or public repository?  Did the graph come up before it crashed?

[Juan Fonseca]

The repo is local. The Repository Browser comes up before SlickEdit crashes.

[Dan]

Can you upload the core file?

[Juan Fonseca]

Where do I find it?

[Dan]

I believe it will be in the current directory of the editor when it crashed.

[Juan Fonseca]

I don't see any files generated in the pwd after the crash. This is all I get.

Segmentation fault

[1]+  Exit 139                ~/slickedit-pro2018beta4/bin/vs

[Juan Fonseca]

Also, I can not reproduce the crash on Windows 7.

[patrick]

So a few possibilities with the core file. 

It could be that core file generation is disabled.  If you run "ulimit -c" and it comes back with "0", then that's the case. You can run "ulimit -c unlimited" from the shell prompt, then run SlickEdit from that shell, and reproduce the crash.

Once it's generated, there are a few places it could be.  The old default location is the working directory of the process when it crashed.  Most of the time, this will be the root directory of your open project - the directory the .vpw file resides in.

If your version of Mint uses apport, then the file will be in /var/crash.

If it's not there, cat /proc/sys/kernel/core_pattern.  This will give us either a location pattern for where the core dumps are configured to be dropped on your system, or the program that handles dumps.

If you locate the dump, we'll PM you with instructions on how to upload it to us.
 

[Juan Fonseca]

"ulimit -c" returned "0", I ran "ulimit -c unlimited" and got the following message after the error.

~/slickedit-pro2018beta4/bin/vs
Segmentation fault (core dumped)

cat /proc/sys/kernel/core_pattern printed the word core.

I don't see any output files in any of the locations from the last message.

[patrick]

Well, from that pattern, it should just be "core" in the working directory the SlickEdit process when it crashed.  It's possible that our git support code had changed the working directory temporarily when the crash happened, which could complicate matters.

If you can't find the file named "core" in any subdirectories of your source tree, we can do an end run and try to get a backtrace directly with gdb, assuming you have gdb installed.  Almost as good as a core file.

• Start slickedit with gdb like this: gdb /PATH/TO/SLICKEDIT/INSTALL/bin/vs_exe
• At the gdb prompt, type "run" and hit enter.  Slickedit should start up.  Reproduce the crash.
• Once it crashes, the gdb prompt should come back.  Type in "bt", hit enter, and post the output you got

[Juan Fonseca]

I found the core file, it put it in the directory of the file that was opened when it crashed.
How do I get it to you?

[SlickEdit Support]

PM with upload instructions sent.

SlickEdit Support

[at5dapa1]

I think I see the same but on Windows 7 x64. Coredump and extra details uploaded to "CAS-71094-K4SF" (7-zip split in two parts).

[Dan]

I asked this before but I want to rephrase it to be sure I know the answer.  This is not a public repository, right?  There's no way I can get access to it?

@at5dapa1 is the issue you're seeing with a private repository?