Disabling sigsegv handler

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Disabling sigsegv handler

Mads Martin Joergensen
Hey vim users,

Anyone knows how to disable the sigsegv handler, so it's possible to get
a core dump when vim segfaults?

--
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.
Reply | Threaded
Open this post in threaded view
|

Re: Disabling sigsegv handler

Groleo Marius
On 9/27/05, Mads Martin Joergensen <[hidden email]> wrote:

> Hey vim users,
>
> Anyone knows how to disable the sigsegv handler, so it's possible to get
> a core dump when vim segfaults?
>
> --
> Mads Martin Joergensen, http://mmj.dk
> "Why make things difficult, when it is possible to make them cryptic
>  and totally illogical, with just a little bit more effort?"
>                                 -- A. P. J.
>

ulimit -c unlimited ( if you're using bash).
If vim segfaults, will drop a core in the current working directory.
Sometimes may happed to drop a core in your home directory( ~ ).



--
Regards, Groleo!

# Use "Reply to All" on mailing lists.
# touch universe
# chmod +x universe
# ./universe
Reply | Threaded
Open this post in threaded view
|

Re: Disabling sigsegv handler

Mads Martin Joergensen
* Groleo Marius <[hidden email]> [Sep 27. 2005 10:19]:
> > Anyone knows how to disable the sigsegv handler, so it's possible to get
> > a core dump when vim segfaults?
>
> ulimit -c unlimited ( if you're using bash).
> If vim segfaults, will drop a core in the current working directory.
> Sometimes may happed to drop a core in your home directory( ~ ).

I know about ulimit and that's already set to unlimited. The reason I
wanted to turn of the signal handler is this snippet from an incomplete
backtrace (vim hangs in a segfault):

#12 0x080f8104 in deathtrap (sigarg=6) at os_unix.c:933
#13 <signal handler called>
#14 0xffffe410 in __kernel_vsyscall ()
#15 0x400ae501 in raise () from /lib/tls/libc.so.6
#16 0x400afd7b in abort () from /lib/tls/libc.so.6
#17 0x400e4875 in __libc_message () from /lib/tls/libc.so.6
#18 0x400ea802 in malloc_printerr () from /lib/tls/libc.so.6
#19 0x400eb1b4 in free () from /lib/tls/libc.so.6
#20 0x080b8d60 in ml_close (buf=0x401a1ff4, del_file=0) at memline.c:553
#21 0x080b8e2a in ml_close_notmod () at memline.c:597
#22 0x080c81c7 in preserve_exit () at misc1.c:7593
#23 <signal handler called>
#24 0x400f2013 in memmove () from /lib/tls/libc.so.6
#25 0xffffffdc in ?? ()
#26 0x080c94de in ins_char_bytes (buf=0xbffac33b "i", charlen=1) at
string3.h:64

--
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.
Reply | Threaded
Open this post in threaded view
|

Re: Disabling sigsegv handler

Bram Moolenaar

Mads Martin Joergensen wrote:

> * Groleo Marius <[hidden email]> [Sep 27. 2005 10:19]:
> > > Anyone knows how to disable the sigsegv handler, so it's possible to get
> > > a core dump when vim segfaults?
> >
> > ulimit -c unlimited ( if you're using bash).
> > If vim segfaults, will drop a core in the current working directory.
> > Sometimes may happed to drop a core in your home directory( ~ ).
>
> I know about ulimit and that's already set to unlimited. The reason I
> wanted to turn of the signal handler is this snippet from an incomplete
> backtrace (vim hangs in a segfault):
>
> #12 0x080f8104 in deathtrap (sigarg=6) at os_unix.c:933
> #13 <signal handler called>
> #14 0xffffe410 in __kernel_vsyscall ()
> #15 0x400ae501 in raise () from /lib/tls/libc.so.6
> #16 0x400afd7b in abort () from /lib/tls/libc.so.6
> #17 0x400e4875 in __libc_message () from /lib/tls/libc.so.6
> #18 0x400ea802 in malloc_printerr () from /lib/tls/libc.so.6
> #19 0x400eb1b4 in free () from /lib/tls/libc.so.6
> #20 0x080b8d60 in ml_close (buf=0x401a1ff4, del_file=0) at memline.c:553
> #21 0x080b8e2a in ml_close_notmod () at memline.c:597
> #22 0x080c81c7 in preserve_exit () at misc1.c:7593
> #23 <signal handler called>
> #24 0x400f2013 in memmove () from /lib/tls/libc.so.6
> #25 0xffffffdc in ?? ()
> #26 0x080c94de in ins_char_bytes (buf=0xbffac33b "i", charlen=1) at
> string3.h:64

Vim tries hard to avoid looping in deathtrap().  The situation that
free() crashes (corrupted memory administration) is specifically
handled.  You only show a short part of the stack, thus I can't see why
it happens for you.  Could be something Linux-specific.

--
If "R" is Reverse, how come "D" is FORWARD?

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: Disabling sigsegv handler

A.J.Mechelynck
----- Original Message -----
From: "Bram Moolenaar" <[hidden email]>
To: "Mads Martin Joergensen" <[hidden email]>
Cc: <[hidden email]>
Sent: Tuesday, September 27, 2005 12:05 PM
Subject: Re: Disabling sigsegv handler
[...]
> If "R" is Reverse, how come "D" is FORWARD?

Because in Reverse you are moving this <--- way, but in forwarD you are
moving the other ---> way.

:-)
Tony.

>
> /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
> ///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ 
> \\\
> \\\              Project leader for A-A-P -- http://www.A-A-P.org 
> ///
> \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///


Reply | Threaded
Open this post in threaded view
|

Re: Disabling sigsegv handler

Mads Martin Joergensen
In reply to this post by Bram Moolenaar
* Bram Moolenaar <[hidden email]> [Sep 27. 2005 12:05]:
> Vim tries hard to avoid looping in deathtrap().  The situation that
> free() crashes (corrupted memory administration) is specifically
> handled.  You only show a short part of the stack, thus I can't see why
> it happens for you.  Could be something Linux-specific.

#0  0xffffe410 in __kernel_vsyscall ()
#1  0x4015141e in __lll_mutex_lock_wait () from /lib/tls/libc.so.6
#2  0x400eeae4 in _L_mutex_lock_3518 () from /lib/tls/libc.so.6
#3  0x40136503 in __write_nocancel () from /lib/tls/libc.so.6
#4  0x08162ae8 in ?? ()
#5  0x00000001 in ?? ()
#6  0x401a1ff4 in ?? () from /lib/tls/libc.so.6
#7  0x0815d6e4 in ?? ()
#8  0x080b8d60 in ml_close (buf=0x817b8c8, del_file=-4) at memline.c:553
#9  0x080b8d60 in ml_close (buf=0x401a1ff4, del_file=-4) at memline.c:553
#10 0x080b8ddc in ml_close_all (del_file=1075123230) at memline.c:580
#11 0x080f83f1 in mch_exit (r=-4) at os_unix.c:2718
#12 0x080f8104 in deathtrap (sigarg=6) at os_unix.c:933
#13 <signal handler called>
#14 0xffffe410 in __kernel_vsyscall ()
#15 0x400ae501 in raise () from /lib/tls/libc.so.6
#16 0x400afd7b in abort () from /lib/tls/libc.so.6
#17 0x400e4875 in __libc_message () from /lib/tls/libc.so.6
#18 0x400ea802 in malloc_printerr () from /lib/tls/libc.so.6
#19 0x400eb1b4 in free () from /lib/tls/libc.so.6
#20 0x080b8d60 in ml_close (buf=0x401a1ff4, del_file=0) at memline.c:553
#21 0x080b8e2a in ml_close_notmod () at memline.c:597
#22 0x080c81c7 in preserve_exit () at misc1.c:7593
#23 <signal handler called>
#24 0x400f2013 in memmove () from /lib/tls/libc.so.6
#25 0xffffffdc in ?? ()
#26 0x080c94de in ins_char_bytes (buf=0xbffac33b "i", charlen=1) at
string3.h:64
#27 0x080c9830 in ins_char (c=-506198) at misc1.c:1787
#28 0x0805bb37 in insertchar (c=105, flags=0, second_indent=-1) at edit.c:4357
#29 0x0805cd78 in insert_special (c=105, allow_modmask=<value optimized out>,
ctrlv=0) at edit.c:3829
#30 0x080601e8 in edit (cmdchar=105, startln=0, count=1) at edit.c:1310
#31 0x080dd68a in invoke_edit (cap=0xbffac52c, repl=<value optimized out>,
cmd=105, startln=-506198)
    at normal.c:8180
#32 0x080e1fe2 in normal_cmd (oap=0xbffac594, toplevel=1) at normal.c:1116
#33 0x080add51 in main_loop (cmdwin=0) at main.c:2183
#34 0x080b31d2 in main (argc=0, argv=0xbffac774) at main.c:2001
---Type <return> to continue, or q <return> to quit---
#35 0x4009be60 in __libc_start_main () from /lib/tls/libc.so.6
#36 0x0804a761 in _start () at start.S:119

$  vim --version
VIM - Vi IMproved 6.3 (2004 June 7, compiled Sep 13 2005 00:07:43)
Included patches: 1-84
Compiled by abuild@gershwin
Big version without GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent
-clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+cryptv +cscope +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags +eval
+ex_extra +extra_search +farsi +file_in_path +find_in_path +folding -footer
+fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap
 +libcall +linebreak +lispindent +listcmds +localmap +menu +mksession
+modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm
+mouse_netterm +mouse_xterm +multi_byte +multi_lang -netbeans_intg -osfiletype
+path_extra -perl +postscript +printer -python +quickfix +rightleft -ruby
+scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax
+tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse
+textobjects +title -toolbar +user_commands +vertsplit +virtualedit +visual
+visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup
-X11 -xfontset -xim -xsmp -xterm_clipboard -xterm_save
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/etc"
 f-b for $VIMRUNTIME: "/usr/share/vim/current"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -Wall -pipe -fno-strict-aliasing      
Linking: gcc   -L/usr/local/lib -o vim       -lncurses -lacl      

--
Mads Martin Joergensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
 and totally illogical, with just a little bit more effort?"
                                -- A. P. J.
Reply | Threaded
Open this post in threaded view
|

Re: Disabling sigsegv handler

Bram Moolenaar

Mads Martin Joergensen wrote:

> * Bram Moolenaar <[hidden email]> [Sep 27. 2005 12:05]:
> > Vim tries hard to avoid looping in deathtrap().  The situation that
> > free() crashes (corrupted memory administration) is specifically
> > handled.  You only show a short part of the stack, thus I can't see why
> > it happens for you.  Could be something Linux-specific.
>
> #0  0xffffe410 in __kernel_vsyscall ()

[etc.]

Hmm, this doesn't show a loop.  Vim first tries to exit nicely,
preserving swap files, if that fails then use mch_exit(), then exit with
exit() (deletes temp files), then with _exit().  Thus deathtrap() may be
called four (five?) times without actually looping.

> $  vim --version
> VIM - Vi IMproved 6.3 (2004 June 7, compiled Sep 13 2005 00:07:43)

I did improve it a bit for Vim 7.  I didn't make a patch for Vim 6.3,
because it requires more testing.  But I can't tell if your situation is
handled better in Vim 7.  Hopefully the crash doesn't happen at all!

--
A hamburger walks into a bar, and the bartender says: "I'm sorry,
but we don't serve food here."

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///
Reply | Threaded
Open this post in threaded view
|

Re: Disabling sigsegv handler

Bram Moolenaar
In reply to this post by Mads Martin Joergensen

Mads Martin Joergensen wrote:

> * Bram Moolenaar <[hidden email]> [Sep 27. 2005 13:56]:
> > > > Vim tries hard to avoid looping in deathtrap().  The situation that
> > > > free() crashes (corrupted memory administration) is specifically
> > > > handled.  You only show a short part of the stack, thus I can't
> > > > see why it happens for you.  Could be something Linux-specific.
> > >
> > > #0  0xffffe410 in __kernel_vsyscall ()
>
> I've now gotten a nice valgrind trace that shows where the problem might
> reside. Hope it's useful:
>
> ==9379== Conditional jump or move depends on uninitialised value(s)
> ==9379==    at 0x80BB88E: msg_puts_attr_len (message.c:1816)
> ==9379==    by 0x80BA77F: msg_outtrans_len_attr (message.c:1310)
> ==9379==    by 0x80BA540: msg_outtrans_len (message.c:1201)
> ==9379==    by 0x808CD0D: draw_cmdline (ex_getln.c:2345)
> ==9379==    by 0x808D0D8: put_on_cmdline (ex_getln.c:2507)
> ==9379==    by 0x808C220: getcmdline (ex_getln.c:1537)
> ==9379==    by 0x808C86E: getexline (ex_getln.c:1864)
> ==9379==    by 0x807CB26: do_cmdline (ex_docmd.c:881)
> ==9379==    by 0x80D4EE9: nv_colon (normal.c:4764)
> ==9379==    by 0x80D0673: normal_cmd (normal.c:1116)
> ==9379==    by 0x80A8D2A: main_loop (main.c:2183)
> ==9379==    by 0x80A8AAA: main (main.c:2001)
> ==9379==
> ==9379== Conditional jump or move depends on uninitialised value(s)
> ==9379==    at 0x80FF652: screen_puts_len (screen.c:5477)
> ==9379==    by 0x80BB93F: t_puts (message.c:2161)
> ==9379==    by 0x80BB8C6: msg_puts_attr_len (message.c:2144)
> ==9379==    by 0x80BA77F: msg_outtrans_len_attr (message.c:1310)
> ==9379==    by 0x80BA540: msg_outtrans_len (message.c:1201)
> ==9379==    by 0x808CD0D: draw_cmdline (ex_getln.c:2345)
> ==9379==    by 0x808D0D8: put_on_cmdline (ex_getln.c:2507)
> ==9379==    by 0x808C220: getcmdline (ex_getln.c:1537)
> ==9379==    by 0x808C86E: getexline (ex_getln.c:1864)
> ==9379==    by 0x807CB26: do_cmdline (ex_docmd.c:881)
> ==9379==    by 0x80D4EE9: nv_colon (normal.c:4764)
> ==9379==    by 0x80D0673: normal_cmd (normal.c:1116)
> ==9379==    by 0x80A8D2A: main_loop (main.c:2183)
> ==9379==    by 0x80A8AAA: main (main.c:2001)

Hmm, not very clear what happens here.

Can you use the efence library?  Or some other memory checker?  If it's
uninitialized memory reproducing the problem can be difficult, you need
to use a tool that detects it.

--
I am always surprised in the Linux world how quickly solutions can be
obtained.  (Imagine sending an email to Bill Gates, asking why Windows
crashed, and how to fix it...  and then getting an answer that fixed the
problem... <0>_<0> !)              -- Mark Langdon

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\     Buy LOTR 3 and help AIDS victims -- http://ICCF.nl/lotr.html   ///