Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory fault-coredump unix aix #137

Closed
GoogleCodeExporter opened this issue Aug 18, 2015 · 5 comments
Closed

Memory fault-coredump unix aix #137

GoogleCodeExporter opened this issue Aug 18, 2015 · 5 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1.Edit a text file with 25000 lignes, about 3200 chars length every line
2.Split the lines to have 1600 chars length every, using a command like:
  %s/word1, word2/word1,\r word2/
  where word1 and word2 exists on every line at the middle (about).
3.After, I had a Memory fault(coredump), the message :
  Vim: Caught deadly signal SEGV
  Vim: Finished.
  Memory fault(coredump)

What is the expected output? 
  The lines of text file have 1600 chars length.

What do you see instead?
  Vim: Caught deadly signal SEGV
  Vim: Finished.
  Memory fault(coredump)

What version of the product are you using? 
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Dec 11 2012 16:21:02)
Included patches: 1-754
Compiled by l1234u
Normal 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
-conceal +cryptv -cscope +cursorbind +cursorshape +dialog_con +diff +digraphs
-dnd -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi +file_in_path
+find_in_path +float +folding -footer +fork() -gettext -hangul_input -iconv
+insert_expand +jumplist -keymap -langmap +libcall +linebreak +lispindent
+listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape
-mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_sgr -mouse_sysmouse
-mouse_urxvt +mouse_xterm -multi_byte +multi_lang -mzscheme +netbeans_intg
+path_extra -perl +persistent_undo +postscript +printer -profile -python
-python3 +quickfix +reltime -rightleft -ruby +scrollbind +signs +smartindent
-sniff +startuptime +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_interact +xterm_clipboard -xterm_save
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: cc -qlanglvl=extc89 -c -I. -Iproto -DHAVE_CONFIG_H     -g
Linking:
cc -qlanglvl=extc89    -o vim       -lSM -lICE -lXt -lX11    -lm -lcurses

On what operating system?
Aix 6.1

Please provide any additional information below.
Using the debugging tool on  Aix 6.1, dbx , vim binary and core dump the stack 
at the crash was:

[using memory image in core]
reading symbolic information ...

Segmentation fault in may_core_dump at line 3166 in file "os_unix.c"
 3166           kill(getpid(), deadly_signal);  /* Die using the signal we caught */
(dbx) where
may_core_dump(), line 3166 in "os_unix.c"
mch_exit(r = 1), line 3132 in "os_unix.c"
getout(exitval = 1), line 1478 in "main.c"
libdebug assertion "(framep->getGpr(STKP, &addr) == DB_SUCCESS && *nextStkpp == 
addr)" failed at line 1299 in file 
../../../../../../../../../../../src/bos/usr/ccs/lib/libdbx/libdebug/modules/sta
ckdebug/POWER/stackdb_FrameProgress.C
preserve_exit(), line 9134 in "misc1.c"
deathtrap(sigarg = 11), line 1097 in "os_unix.c"
(dbx)

Best regards !

Original issue reported on code.google.com by Zulolox4...@gmail.com on 25 May 2013 at 6:17

@GoogleCodeExporter
Copy link
Author

The stack provided is not very useful unfortunately.
The debugger is not able to show the stack beyond the signal handler 
'deathtrap' somehow.

I would suggest to comment out the set up of this signal handler, and try to 
reproduce the bug. The stack trace will then hopefully be more useful. In other 
words, try to comment out the line "catch_signals(deathtrap, SIG_ERR);" in 
os_unix.c:1332 as follows:

diff -r fcd8be759157 src/os_unix.c
--- a/src/os_unix.c Fri Jun 21 18:31:23 2013 +0200
+++ b/src/os_unix.c Sat Jun 22 06:23:29 2013 +0200
@@ -1329,7 +1329,7 @@
     /*
      * Arrange for other signals to gracefully shutdown Vim.
      */
-    catch_signals(deathtrap, SIG_ERR);
+    /* catch_signals(deathtrap, SIG_ERR); */

 #if defined(FEAT_GUI) && defined(SIGHUP)
     /*


Then provide the stack again.

I don't have IBM AIX so I cannot reproduce this. But I used
IBM AIX a long time ago and I remember one difference with Linux: 
malloc(0) returned NULL on AIX whereas malloc(0) returns a
valid address of 0 allocated bytes on Linux. Well, I see that
Vim lalloc() treats 0 size allocation as error so I don't think
that's the issue anyway.

I also see that you're also using Vim-7.3.754. The latest version
is Vim-7.3.1224.  It would be best to reproduce it with the latest
version if possible, in case the bug has already been fixed.
You could also try to download the latest Vim with Mercurial:

$ hg clone https://vim.googlecode.com/hg/ vim


Original comment by dominiqu...@gmail.com on 22 Jun 2013 at 4:32

@GoogleCodeExporter
Copy link
Author

Is this still relevant? If yes, can you post an updated stack trace?

Original comment by chrisbr...@googlemail.com on 9 Jan 2015 at 12:30

@GoogleCodeExporter
Copy link
Author

Hello,
Thanks for asking about the old vim 7.3 crash problem.
Compiled Jan 07 2015, the Vim version 7.4.567, (but used old makefiles, before 
vim 7.4.475 and your patch solution for os_unix.c, from issue 265) and until 
now I don't any problem !

Original comment by Zulolox4...@gmail.com on 18 Jan 2015 at 11:52

@GoogleCodeExporter
Copy link
Author

Hi

It's working nice vim 7.4.567 on AIX 6.1 TL6, compiled with  IBM XL C/C++ for 
AIX, V11.1
Version: 11.01.0000.0006, not very old fix (6) for C compiler -> 2011 MAY 20

Best regards !

Original comment by Zulolox4...@gmail.com on 19 Jan 2015 at 7:18

@GoogleCodeExporter
Copy link
Author

Closing, since the problem can't be reproduced.

Original comment by brammool...@gmail.com on 20 Jan 2015 at 9:59

  • Changed state: WontFix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant