SlickEdit Community

Archived Beta Discussions => SlickEdit 201x Beta Discussions => SlickEdit 2016 v21 Beta Discussion => Topic started by: jc44 on September 09, 2016, 12:45:17 PM

Title: B5 linux: crash
Post by: jc44 on September 09, 2016, 12:45:17 PM
B5 linux (Ubuntu 14.04) x64: I have a (currently) reliable SE crash.

For some reason that utterly eludes me I can't get a core dump out of the system, but I did have gdb attached and have a backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000855e67 in crt2_t::updateForBlockSelection(crt2_t*) ()
(gdb) bt
#0  0x0000000000855e67 in crt2_t::updateForBlockSelection(crt2_t*) ()
#1  0x00000000006a71dd in setmark2(fileview_t*, int, fileview_t*, crt2_t*) ()
#2  0x00000000006a794a in filewindow_t::mark_to_cursor(bool, bool, bool) ()
#3  0x00000000006ac2b6 in vswBeginSelect(filewindow_t*, int, int, int, int, int) ()
#4  0x00000000006acbaa in BeginSelectOp(int) ()
#5  0x0000000000590942 in run_proc(int) ()
#6  0x0000000000581310 in run_proc_immediate2(m_s*, int, int, VSARGTYPE*, int, int) [clone .isra.13] ()
#7  0x0000000000581fdd in run_proc_immediate(int, int, VSARGTYPE*, int, int) ()
#8  0x0000000000792df5 in se_call_index(filewindow_t*, int, int, int, VSARGTYPE*, bool) ()
#9  0x00000000006e6dd5 in vsClexSkipBlanks ()
#10 0x000000000058ee43 in call_dllpc(int, int, namelist_t*) ()
#11 0x0000000000590942 in run_proc(int) ()
#12 0x0000000000581310 in run_proc_immediate2(m_s*, int, int, VSARGTYPE*, int, int) [clone .isra.13] ()
#13 0x0000000000582092 in run_callback_immediate(VSCALLPTR*, int, VSARGTYPE*, int) ()
#14 0x0000000000792d1f in se_call_callback(filewindow_t*, VSCALLPTR*, int, int, VSARGTYPE*) ()
#15 0x0000000000651007 in vs_execute_timer_event(int) ()
#16 0x00007fcd5c361a89 in QObject::event(QEvent*) ()
---Type <return> to continue, or q <return> to quit---
   from /home/johncox/bin/se21b5/bin/libQtCore.so.4
#17 0x00007fcd5c906afa in QWidget::event(QEvent*) ()
   from /home/johncox/bin/se21b5/bin/libQtGui.so.4
#18 0x00007fcd5c8b4ab4 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
    () from /home/johncox/bin/se21b5/bin/libQtGui.so.4
#19 0x00007fcd5c8b9858 in QApplication::notify(QObject*, QEvent*) ()
   from /home/johncox/bin/se21b5/bin/libQtGui.so.4
#20 0x00007fcd5c34988c in QCoreApplication::notifyInternal(QObject*, QEvent*)
    () from /home/johncox/bin/se21b5/bin/libQtCore.so.4
#21 0x00007fcd5c3797b2 in ?? ()
   from /home/johncox/bin/se21b5/bin/libQtCore.so.4
#22 0x00007fcd5c376fed in ?? ()
   from /home/johncox/bin/se21b5/bin/libQtCore.so.4
#23 0x00007fcd5c377011 in ?? ()
   from /home/johncox/bin/se21b5/bin/libQtCore.so.4
#24 0x00007fcd56aade04 in g_main_dispatch (context=0x421b230)
    at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3064
#25 g_main_context_dispatch (context=context@entry=0x421b230)
    at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3663
#26 0x00007fcd56aae048 in g_main_context_iterate (
    context=context@entry=0x421b230, block=block@entry=1,
    dispatch=dispatch@entry=1, self=<optimised out>)
    at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3734
---Type <return> to continue, or q <return> to quit---
#27 0x00007fcd56aae0ec in g_main_context_iteration (context=0x421b230,
    may_block=1) at /build/buildd/glib2.0-2.40.2/./glib/gmain.c:3795
#28 0x00007fcd5c37791f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /home/johncox/bin/se21b5/bin/libQtCore.so.4
#29 0x00007fcd5c95984e in ?? () from /home/johncox/bin/se21b5/bin/libQtGui.so.4
#30 0x00007fcd5c3482d2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /home/johncox/bin/se21b5/bin/libQtCore.so.4
#31 0x00007fcd5c348527 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /home/johncox/bin/se21b5/bin/libQtCore.so.4
#32 0x00007fcd5c34d7e7 in QCoreApplication::exec() ()
   from /home/johncox/bin/se21b5/bin/libQtCore.so.4
#33 0x00000000004ebe1a in vmain(int, char**) ()
#34 0x000000000150d829 in xmain ()
#35 0x000000000049e439 in main ()
(gdb) generate-core-file se_template_crash
Couldn't get registers: No such process.
(gdb) ### Bother!

The crash occurs when editing the code snippet below (there is a lot more stuff in the file) when I type a < after "Safe<MmalTrampoline" on the second line:

template <class T>
class MmalTrampoline : public base::RefCountedThreadSafe<MmalTrampoline>
{
  base::Lock lock_;
  VideoFrame::MmalResizeCB resize_cb_;
 
I briefly see SE fill in <T> and then it dies.
Title: Re: B5 linux: crash
Post by: Dan on September 09, 2016, 01:37:04 PM
Can you send your tag file and zip up your config and send it?  We don't need anything under vsdelta.
Title: Re: B5 linux: crash
Post by: patrick on September 09, 2016, 03:12:30 PM
Actually, we're going to have to send you a debug executable for this one.  We'll send a PM with the download information for you.  What we need you do to is backup the vs_exe file that's in your current beta5 install directory, and replace it with the downloaded debug vs_exe.  And then just reproduce the crash so it dumps a core.  In this case, I suspect just the stack trace isn't necessarily going to tell us everything we want to know, so we'll need to try to get the core file.

As for the core files not showing up, that could be two things that I know of.  One is the ulimit - if you run "ulimit -c" from the shell, and it says "0", then the ulimit is preventing the core file from being created.  To get around this, you can run "ulimit -c unlimited" in a shell, and then start SlickEdit from that shell.  (when set like this, the ulimit setting is inherited like an env variable, so you have to start it from the same shell you ran the ulimit from).

The other (maybe more likely) thing is that the apport crash reporting system is enabled on your system.  In that case, the core is generated in the /var/crash directory - it's a packaged version of the core dump file which we can unpack on our end.  Usually, if this is the case, you can see a message in the syslog that names the crashed process, and where it dumped the report file.

We'll send you the upload instructions for the core dump in the PM as well.

Thanks for the report.
Title: Re: B5 linux: crash
Post by: jc44 on September 09, 2016, 03:35:08 PM
Yeah apport does seem to be the culprit stopping the dump (I had already found the ulimit thing):

ERROR: apport (pid 39485) Fri Sep  9 16:26:19 2016: executable: /home/johncox/bin/se21b5/bin/vs_exe (command line "/home/johncox/bin/se21b5/bin/vs_exe")
ERROR: apport (pid 39485) Fri Sep  9 16:26:19 2016: executable does not belong to a package, ignoring

Sadly this a shared server on a client site - I don't feel happy poking its security setup...  If you know of a temporary way of enabling core dumps then I'd happily do that.
Title: Re: B5 linux: crash
Post by: patrick on September 09, 2016, 04:08:57 PM
If you have sudo rights, then it sounds like you can temporarily disable it by running "sudo service apport stop".   

If not, it sounds like you can make it report unpackaged crashes with just a dotfile in your home directory (assuming you're not sharing a home dirctory with others as well).  Create a  $HOME/.config/apport directory, and add a file called "settings" that contains the following:
Code: [Select]
[main]
unpackaged=true

And then see if you can create a core file - it doesn't sound like you need to log out for this to take effect.
Title: Re: B5 linux: crash
Post by: jc44 on September 09, 2016, 04:29:09 PM
If I am truly lucky you should have an apport crash report.  The settings thing was what finally did the trick.  I did manage to disable apport and I could create core files from a simple *(char*)0=99, but for some reason vs just wouldn't generate a core file anywhere I could find despite the fact it said it had :-(
Title: Re: B5 linux: crash
Post by: jc44 on September 09, 2016, 04:41:16 PM
Having said that I've just found where it ended up - it turns up in my se project directory.  I'll send that on too in case the apport thing isn't useful.
Title: Re: B5 linux: crash
Post by: jc44 on September 09, 2016, 04:56:45 PM
... or maybe not - the upload link seems to have become unresponsive.
Title: Re: B5 linux: crash
Post by: link on September 09, 2016, 05:21:11 PM
FYI, I had a crash very similar to yours, crashed in the same function.  I created a support ticket and uploaded a core dump from the crash.
Title: Re: B5 linux: crash
Post by: Clark on September 09, 2016, 06:02:53 PM
Your crashes are due to the same bug. Should be easy to fix.
Title: Re: B5 linux: crash
Post by: b on September 09, 2016, 09:23:27 PM
If I am truly lucky you should have an apport crash report.  The settings thing was what finally did the trick.  I did manage to disable apport and I could create core files from a simple *(char*)0=99, but for some reason vs just wouldn't generate a core file anywhere I could find despite the fact it said it had :-(

I ran into this frustration awhile back trying to get a core for the team here.  Take a look at /proc/sys/kernel/core_pattern (Probably has a value of |/usr/share/apport/apport %p %s %c %P).  So, disabling apport isn't enough.   See http://askubuntu.com/questions/470756/how-to-setup-automatic-core-dump-on-upstart-script (http://askubuntu.com/questions/470756/how-to-setup-automatic-core-dump-on-upstart-script).  You may also find the cores squirreled away in /var/crash
Title: Re: B5 linux: crash
Post by: jc44 on September 12, 2016, 10:01:07 AM
Well I think I now have it sussed:

"sudo service apport stop" does enable core file generation and resets /proc/sys/kernel/core_pattern to "core".  The core file doesn't turn up with the executable - it turns up in SEs "current" directory which in my case was the directory I loaded the project definition (.vpw) file from.

If apport is running then creating $HOME/.config/apport/settings with

[main]
unpackaged=true

in it enables .crash file generation in /var/crash.

I hope that helps other people
Title: Re: B5 linux: crash
Post by: b on September 12, 2016, 06:31:38 PM
Well I think I now have it sussed:

"sudo service apport stop" does enable core file generation and resets /proc/sys/kernel/core_pattern to "core".  The core file doesn't turn up with the executable - it turns up in SEs "current" directory which in my case was the directory I loaded the project definition (.vpw) file from.

If apport is running then creating $HOME/.config/apport/settings with

[main]
unpackaged=true

in it enables .crash file generation in /var/crash.

I hope that helps other people

Thanks for sharing this!   I've updated my configuration for future use.
Title: Re: B5 linux: crash
Post by: jc44 on September 16, 2016, 09:15:47 AM
Hi

I'm now back using linux.  The test SE you sent me by PM seems to fix the problem, RC1 still seems to crash.  I hope that was the expected result.

JC
Title: Re: B5 linux: crash
Post by: Clark on September 16, 2016, 11:34:44 AM
Sadly that fix didn't get checked in for RC 1. Sorry
Title: Re: B5 linux: crash
Post by: jc44 on September 16, 2016, 12:47:25 PM
I have another crash from today (RC1).  Not obviously the same issue - I had deleted a few lines and looked away and it was dead when I looked back - I can't reproduce this.  This time I have a .crash file!  Are you interested in it?
Title: Re: B5 linux: crash
Post by: patrick on September 16, 2016, 01:04:24 PM
Sure, go ahead and post it in the same place you posted the earlier cores.
Title: Re: B5 linux: crash
Post by: jc44 on September 16, 2016, 02:53:26 PM
Now uploaded se21rc1_bin_vs_exe.crash.gz
Title: Re: B5 linux: crash
Post by: patrick on September 16, 2016, 03:06:24 PM
Got it.  Same root cause as the previous crashes, so this should be fixed for RC2.  Stack looks a little different because I believe this happened on a different timer event than your other crahses.

Thanks for sending it in so we could check on it.