Author Topic: RC4 crash in linux, core file size is 0  (Read 1425 times)

rowbearto

  • Senior Community Member
  • Posts: 793
  • Hero Points: 25
RC4 crash in linux, core file size is 0
« on: October 06, 2016, 02:34:27 am »
Hi:

RC4 just crashed on me in linux, segmentation fault. Unfortunately, the size of the core file is 0 bytes.

Before running SE, I used ulimit -c unlimited (I have a script where I do ulimit -c unlimited, then invoke SE).

Any idea why core file is only 0 bytes and how I can get a better one next time?

Rob

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 805
  • Hero Points: 45
Re: RC4 crash in linux, core file size is 0
« Reply #1 on: October 06, 2016, 01:39:52 pm »
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.

rowbearto

  • Senior Community Member
  • Posts: 793
  • Hero Points: 25
Re: RC4 crash in linux, core file size is 0
« Reply #2 on: October 06, 2016, 02:18:21 pm »
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.

Dan

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1959
  • Hero Points: 81
Re: RC4 crash in linux, core file size is 0
« Reply #3 on: October 06, 2016, 02:36:35 pm »
Do you remember what you were doing when the crash occurred?

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 805
  • Hero Points: 45
Re: RC4 crash in linux, core file size is 0
« Reply #4 on: October 06, 2016, 02:49:44 pm »
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. 

rowbearto

  • Senior Community Member
  • Posts: 793
  • Hero Points: 25
Re: RC4 crash in linux, core file size is 0
« Reply #5 on: October 06, 2016, 03:41:39 pm »
I can't repeat it right now (very busy here), but the crash repeated about 3 times in a row yesterday. It think (memory is fuzzy, so I may have an error here) I was doing something like this:

Code: [Select]
typedef struct
{
  int16_t sfn;
  int8_t subframe_num;
  int32_t NB_MAX_PRB_5MHZ
} srs_fft_output_history_t;

The cursor was the left of the N in NB_MAX_PRB and I typed an open bracket [. Then it crashed.

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 805
  • Hero Points: 45
Re: RC4 crash in linux, core file size is 0
« Reply #6 on: October 06, 2016, 04:26:38 pm »
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.


rowbearto

  • Senior Community Member
  • Posts: 793
  • Hero Points: 25
Re: RC4 crash in linux, core file size is 0
« Reply #7 on: October 06, 2016, 06:20:37 pm »
I am using gdb and tried to do a clearcase checkout. But now SE is frozen. Don't know if it is due to running under gdb or something else? Should I stop it in gdb and get a stack trace?

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 805
  • Hero Points: 45
Re: RC4 crash in linux, core file size is 0
« Reply #8 on: October 06, 2016, 06:42:00 pm »
I don't know if they're related.   I haven't seen anything like that when running under GDB before, but I've not done it with ClearCase.

If you want to interrupt the process and get a stack you can go to the gdb window and hit Ctrl-C to interrupt the process.  To get the stacktrace for all threads, run "thread apply all bt".

rowbearto

  • Senior Community Member
  • Posts: 793
  • Hero Points: 25
Re: RC4 crash in linux, core file size is 0
« Reply #9 on: October 06, 2016, 06:46:14 pm »
Here is the output of thread apply all bt

(gdb) thread apply all bt

Thread 13 (Thread 0x7fffe6209700 (LWP 18727)):
#0  0x000000314b00b5bc in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x000000000188b76d in cmWaitable::cond_wait(int) ()
#2  0x000000000188b7d3 in cmWaitHandle::waitOne(int) ()
#3  0x0000000001b7f2bd in fileDateThread::run() ()
#4  0x000000000188ac07 in cmThread::ThreadStartRoutine(void*) ()
#5  0x000000314b0079d1 in start_thread () from /lib64/libpthread.so.0
#6  0x000000314ace88fd in clone () from /lib64/libc.so.6

Thread 8 (Thread 0x7fffe6ae8700 (LWP 13438)):
#0  0x000000314b00b98e in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x000000000188b73c in cmWaitable::cond_wait(int) ()
#2  0x000000000188b7d3 in cmWaitHandle::waitOne(int) ()
#3  0x000000000133412d in slickedit::SEListTagsThread::runAsWriter() ()
#4  0x000000000188ac07 in cmThread::ThreadStartRoutine(void*) ()
#5  0x000000314b0079d1 in start_thread () from /lib64/libpthread.so.0
#6  0x000000314ace88fd in clone () from /lib64/libc.so.6

Thread 7 (Thread 0x7ffff1644700 (LWP 13437)):
#0  0x000000314b00b98e in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x000000000188b73c in cmWaitable::cond_wait(int) ()
#2  0x000000000188b7d3 in cmWaitHandle::waitOne(int) ()
#3  0x0000000001337b51 in slickedit::SEListTagsThread::runAsTagger() ()
#4  0x000000000188ac07 in cmThread::ThreadStartRoutine(void*) ()
#5  0x000000314b0079d1 in start_thread () from /lib64/libpthread.so.0
#6  0x000000314ace88fd in clone () from /lib64/libc.so.6

Thread 6 (Thread 0x7fffe8523700 (LWP 13436)):
#0  0x000000314b00b98e in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x000000000188b73c in cmWaitable::cond_wait(int) ()
#2  0x000000000188b7d3 in cmWaitHandle::waitOne(int) ()
#3  0x0000000001337b51 in slickedit::SEListTagsThread::runAsTagger() ()
#4  0x000000000188ac07 in cmThread::ThreadStartRoutine(void*) ()
#5  0x000000314b0079d1 in start_thread () from /lib64/libpthread.so.0
#6  0x000000314ace88fd in clone () from /lib64/libc.so.6

Thread 5 (Thread 0x7fffe8624700 (LWP 13435)):
#0  0x000000314b00b98e in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x000000000188b73c in cmWaitable::cond_wait(int) ()
#2  0x000000000188b7d3 in cmWaitHandle::waitOne(int) ()
#3  0x0000000001337b51 in slickedit::SEListTagsThread::runAsTagger() ()
#4  0x000000000188ac07 in cmThread::ThreadStartRoutine(void*) ()
#5  0x000000314b0079d1 in start_thread () from /lib64/libpthread.so.0
#6  0x000000314ace88fd in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7fffe8725700 (LWP 13434)):
#0  0x000000314b00b98e in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x000000000188b73c in cmWaitable::cond_wait(int) ()
#2  0x000000000188b7d3 in cmWaitHandle::waitOne(int) ()
#3  0x0000000001333b4b in slickedit::SEListTagsThread::runAsReader() ()
#4  0x000000000188ac07 in cmThread::ThreadStartRoutine(void*) ()
#5  0x000000314b0079d1 in start_thread () from /lib64/libpthread.so.0
#6  0x000000314ace88fd in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7fffe8826700 (LWP 13433)):
#0  0x000000314b00b98e in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x000000000188b73c in cmWaitable::cond_wait(int) ()
#2  0x000000000188b7d3 in cmWaitHandle::waitOne(int) ()
#3  0x0000000001333b4b in slickedit::SEListTagsThread::runAsReader() ()
#4  0x000000000188ac07 in cmThread::ThreadStartRoutine(void*) ()
#5  0x000000314b0079d1 in start_thread () from /lib64/libpthread.so.0
#6  0x000000314ace88fd in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7ffff23cf0a0 (LWP 13416)):
#0  0x000000314b00f2ad in waitpid () from /lib64/libpthread.so.0
#1  0x00000000017344f5 in cmProcess::unixWaitPid(int) ()
#2  0x00000000017346fe in cmProcess::getExitCode() ()
#3  0x0000000001736fb8 in cmProcess::shell(cmStringT<char, 1, 30> const&, cmProcessFlags, cmStringT<char, 1, 30> const&, cmStringT<char, 1, 30> const&) ()
#4  0x00000000007932d9 in shrink_runpgm(VSLSTR*, VSLSTR*, int*, int, int, int, int, int*, int, slickedit::SEString const&) ()
#5  0x00000000007948fe in execute_command(VSLSTR*, int, int*, slickedit::SEString const&) ()
#6  0x0000000000795742 in pshell_op() ()
#7  0x00000000005903e2 in run_proc(int) ()
#8  0x0000000000580db0 in run_proc_immediate2(m_s*, int, int, VSARGTYPE*, int, int) [clone .isra.13] ()
#9  0x0000000000581a7d in run_proc_immediate(int, int, VSARGTYPE*, int, int)
    ()
#10 0x0000000000793991 in se_call_proc(filewindow_t*, char const*, int, int, VSARGTYPE*) ()
#11 0x0000000000730d82 in vsNotAllowedInReadOnlyMode(int) ()
#12 0x0000000000745503 in vs_call_key_new(filewindow_t*, int, int) ()
#13 0x000000000064118a in gui_edit_event_message ()
#14 0x00000000005e6e7a in vsCtlSlickCExecuteEvent ()
#15 0x00000000005e9951 in vsQTSlickCExecuteKeyEvent ()
#16 0x00007ffff748775c in QWidget::event(QEvent*) ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtGui.so.4
#17 0x00007ffff78a87a6 in QFrame::event(QEvent*) ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtGui.so.4
#18 0x00007ffff7925493 in QAbstractScrollArea::event(QEvent*) ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtGui.so.4
#19 0x00007ffff7434ab4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtGui.so.4
#20 0x00007ffff7439c4e in QApplication::notify(QObject*, QEvent*) ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtGui.so.4
#21 0x00007ffff6ec888c in QCoreApplication::notifyInternal(QObject*, QEvent*)
    ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtCore.so.4
#22 0x00007ffff74d58b9 in ?? ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtGui.so.4
#23 0x00007ffff74d5cb5 in ?? ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtGui.so.4
#24 0x00007ffff74b1fd4 in QApplication::x11ProcessEvent(_XEvent*) ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtGui.so.4
#25 0x00007ffff74d9bb2 in ?? ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtGui.so.4
#26 0x000000314c040642 in g_main_context_dispatch ()
   from /lib64/libglib-2.0.so.0
#27 0x000000314c044c98 in ?? () from /lib64/libglib-2.0.so.0
#28 0x000000314c044e4c in g_main_context_iteration ()
   from /lib64/libglib-2.0.so.0
#29 0x00007ffff6ef691f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtCore.so.4
#30 0x00007ffff74d984e in ?? ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtGui.so.4
#31 0x00007ffff6ec72d2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtCore.so.4
#32 0x00007ffff6ec7527 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtCore.so.4
#33 0x00007ffff6ecc7e7 in QCoreApplication::exec() ()
   from /net/usmhvcitrusfile2/vol/Repositories/lte_scratchpad/robb/slickedit/se21_rc4/bin/libQtCore.so.4
#34 0x00000000004eb66a in vmain(int, char**) ()
#35 0x000000000151c749 in xmain ()
#36 0x000000000049db99 in main ()
Command execution time: 0.040993 (cpu), 0.062114 (wall)
Space used: 55934976 (+6434816 for this command)
(gdb)                                                     

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 805
  • Hero Points: 45
Re: RC4 crash in linux, core file size is 0
« Reply #10 on: October 06, 2016, 07:00:49 pm »
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.