As long as there's sufficient disk space and with that ulimit, I know of no reason why the core file would be truncated to 0 bytes. Especially if you're already writing files to that directory with SlickEdit anyway.

While I've never seen it myself, I've just read a couple of articles that say people have had this problem when the directory the core file was written to was a NFS or other network mount. Is the directory your core file in a network mount, or on a local drive? If it is a network share, you can actually change the location where Linux dumps cores, so you can force all cores to go to /tmp or some other local filesystem you have write access to. This article descibes how to set this up: https://sigquit.wordpress.com/2009/03/13/the-core-pattern/ It's not a new feature, but if you don't have the /proc/sys/kernel/core_pattern file it talks about, then your kernel predates it.

It is in a clearcase view directory, so not NFS, but it is MVFS file system. There is plenty of space there. I don't have admin rights and our IT department is very bureaucratic so not sure I can change the location of where crash dumps are stored unless it can be done as non-root user.

From a quick read of some support docs on MVFS, it sounds like it could have a similar problem to NFS, maybe depending on what type of view it was.

The only other thing I can think of then is to manually change your working directory using the "cd" command on the SlickEdit command line to something like /tmp. That's not a great option, because anything that's doing relative paths will probably not be happy about it, so it may cause you path not found problems.

Actually one other thing I forgot. Though not as good as having a core dump, another thing you can try is running SlickEdit from gdb. So at a shell prompt, run "gdb VS_INSTALL_DIR/bin/vs_exe". And then at the first gdb prompt when it comes up, type in "run", and SlickEdit should start. If there's a crash, the gdb prompt will return, and then you can type in "bt", which will at least give us a stack trace to work with.

Yeah, looks like we're stuck waiting for the clearcase command to complete. I don't know enough about ClearCase to say whether there's a way to see why it's hanging. If it works fine outside of GDB for some reason, that just leaves trying to run with a different working directory to try to have the core dump on a local file system.