Issue 137 in vim: Memory fault-coredump unix aix

[v...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 137 by Zulolox4...@gmail.com: Memory fault-coredump unix aix
http://code.google.com/p/vim/issues/detail?id=137

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/stackdebug/POWER/stackdb_FrameProgress.C
preserve_exit(), line 9134 in "misc1.c"
deathtrap(sigarg = 11), line 1097 in "os_unix.c"
(dbx)

Best regards !

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[Zulox4]

Somebody knows how to debug, and find the bug ? Thanks

[Christian Brabandt]

Hi Zulox4!

A couple of questions. You seem to have only provided half of the
complete backtrace. Can you provide the complete backtrace?
Can you reproduce it when starting vim with vim -u NONE -N -i NONE?
Can you provide the file which you used to cause the crash?

regards,
Christian

[Zulox4]

Hello Christian,
Thanks for helping!
I tested with: vim -u NONE -N -i NONE, I have same crash, a copy paste from the line command:
-------begin-dbx-trace------
/home/vim7_3_754/src$ dbx vim core
Type 'help' for help.

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

Segmentation fault in may_core_dump at line 3166 in file "os_unix.c" ($t1)

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/stackdebug/POWER/stackdb_FrameProgress.C
preserve_exit(), line 9134 in "misc1.c"
deathtrap(sigarg = 11), line 1097 in "os_unix.c"
(dbx)

----------------end-dbx-trace------

The sql file that crashed contains lines with: "insert (col1, col2, ...) values (val1, val2, ...)", has about 128 Mb. The line starting with "insert" word have a length line: 3285 char, and the line starting with "values" word does not change. I tried to split only the 3285 chars line in other two line with a vim command like:

:%s/MM_NOW_MATH, MM_NOW_MATH_DEM/MM_NOW_MATH,\r MM_NOW_MATH_DEM/

at about 1826-th char position.

The file contains about 45000 lines.

An example of a sql insert line, that has in file 2 lines: one starting insert (3285 chars) and other starting with values (1270 chars), here :

insert into FAC_NORM_EXT (NO_PARTITION, NO_TEH, ID_TEH, NO_MATH, ID_MATH, NO_STAR, ID_STAR, ID_CLEAR, CN_TYPE_TEH, IX_INTERNATIONAL, BL_LINE_SPECSTOR, CN_SECTDEM_ACTIVITY, IND_IG, IND_CLEAR_PRO_BABBLE, CN_NAT_ACTION, CN_TYPE_CUSTOM_STO, CN_CONTY, CN_CONTY_BUSINESS, CN_NOTE_INT_SEQUENCE, CN_NOTE_CLEAR, CN_NOTE_CAP_DEV, CN_NOTE_EXTERN_SP, CN_NOTE_EXTERN_MOODYS, ID_CLEAR_MERE, CN_SITE_GEST, CN_LINED_CUSTOM_STO, IND_CTI_CTE, CN_CN_TYP_LOGIC, CN_GROUPS__AFFECTED, BL_GROUPS_AFFECTED, CN_SECTDEM_ACTIVITY_GA, CN_GROUPS_AFFECTED_GE, CN_NOTE_GA, CN_NOTE_EXTERNE_SP_GA, CN_NOTE_EXTERNE_MOODYS_GA, CN_SYSTEME_SOURCE, CN_SYSTEME_COLLECT, CN_METHOD_VALOS, CN_SITE_LANG, CN_SITE_LANG_MATH_ACCR, CN_SITE_ACCOUNTED, CN_SITE_LOCAL, CN_IMPROVMAX, CN_DEVICE_MATH, CN_METIER_ACTIVITY_BFI, IND_MONNAIE_LOCALE_MATH, TXT_TRG, DT_DEBUT_MATH, NB_DUREE_INITIALE_MATH, DT_FINALY__MATH, IND_BIGTAB, IND_CREATED_CONFIRMED, CN_TP_CREANCE, MM_SPECT_PNU_CENTRAL_REAFF_DEM, MM_SPECT_PNU_CNTR_NET_PROV_DEM, CN_SOUS_POOL, CN_POOL, CN_NOTE_FACTOR, NB_DESTINAT, CN_PORT_PRACTICALY, TXT_PORT_EAD, TXT_PORT_PNU, IND_PRISE_EN_COMPTE_PNU, MM_SPECT_EAD_DEM, MM_SPECT_EAD_REGLEMENTAIRE_DEM, IND_EXCEPTION_CAP_DEV, ID_MATH_SOURCE, ID_MATH_MERE, MM_SPECT_NOW_MATH_DEM, CN_SITE_LANG_STAR, CN_DEVICE_STAR, DT_FINALY__STAR, CN_NAME_POSITION, MM_SPECT_STAR_DEM, MM_SPECT_STAR_NET_PROV_DEM, MM_SPECT_MAJ_COOKE_REAL_DEM, MM_SPECT_STIL_DEM, MM_SPECT_STIL_NET_PROV_DEM, MM_SPECT_I_IMP_DEM, MM_SPECT_I_IMP_NET_PROV_DEM, IND_TN, CN_TYPE_AMOVE, CN_PERIOD_AMOVE, TXT_RESTIT, MM_SPECT_RESTIT_DEM, IND_RETAIL, MM_IMPROVMAX_BRUT_DEM, MM_IMPROVMAX_NET_PROV_DEM, MM_PROV_DEM, DT_FINALY__TEH, NB_MATURITE_ECO, ID_ECHEANCIER, CN_ECHEANCIER, TXT_RESTIT_NOW, NB_DURATION, IND_PORTDEM_PNU_TEH, NO_REFERENCE, NO_LINED, CN_FREQ_PAIEMENT, ID_MATH_LOCAL_TEH, CN_CONTY_LANG_MATH, MM_NOW_MATH, MM_NOW_MATH_DEM, MM_STAR, MM_STAR_DEM, IND_MM_EAD_CALCULE, IND_MONNAIE_LOCALE_STAR, TP_APPROCHE, CN_CLASS__EXPO, CN_METIER_TYXS, CN_POOL_TYXS, MM_SPECT_DECOTE_DEM, CN_SS_CLASS__EXPO, CN_TYPE_ENCOURS, CN_TYPE_TEH_ORI, IND_ACTIF_TEH, BL_COMMENT_ADJ, IND_PRISE_PNU_COMPTA, MM_PROV_COL_PU, MM_PROV_COL_PNU, MM_SPECT_PU_NET_N_PROV, MM_SPECT_PNU_NET_N_PROV, MM_ENGA_NET_N_PROV, TP_PERIMETRE_TEH_APC, IND_IP, TXT_E_IG, MM_C_HG_STAR_NET_PR_DEM, MM_C_HG_STAR_DEM, MM_C_HG_RESTIT_DEM, MM_C_HG_PNU_C_NET_PR_DEM, MM_C_HG_PNU_C_REAFF_DEM, MM_C_HG_MAJ_COOKE_RE_DEM, MM_C_HG_I_IMP_NET_PR_DEM, MM_C_HG_I_IMP_DEM, MM_C_HG_STIL_NET_PR_DEM, MM_C_HG_STIL_DEM, MM_C_HG_EAD_REGLEMEN_DEM, MM_C_HG_EAD_DEM, MM_C_HG_DECOTE_DEM, MM_C_HG_NOW_MATH_DEM, MM_HG_PROV_DEM, MM_HG_ENGAG_BRUT_DEM, MM_HG_ENGAG_NET_PROV_DEM, MM_EFFECTIVE_EPE_DEM, TP_CREATED_BAIL, CN_SITE_ACCOUNTED_AP_ACC, CN_METIER_ACT_BFI_AP_ACC, CN_METIER_TYXS_AP_ACC, CN_POOL_TYXS_AP_ACC, DT_PASSAGE_DEFAUT, IND_FILTRAGE_T_PART, CN_ECHELLE_NOTE_SPE, CN_NOTE_CTPR_SPE, PD_CTPR, ID_MODELED_NOTATION, IND_BASCULE_CRF, DT_BASCULE_CRF, TXT_EBLE, ID_MODELED_NOTATION_ORIG, NB_MATURITE_EFFECTIVE, ID_MODELED_EAD, ID_MODELED_LGD, ID_MODELED_LGD_ORIG, CN_SITE_LANG_STAR_ACCR, TXT_E_IG_STAR, IND_CL_INTERCONNECTE, CN_SS_CLASS__EXPO_STD, CN_CLASS__EXPO_STD, ID_PROTOCLASS, IND_PROGAR_IN, NB_IMPROVMAX, MM_STRES_EEPE_DEM, MM_SPECT_EEPE_DEM, MM_SPECT_STRES_EEPE_DEM, MM_C_HG_EEPE_DEM, MM_C_HG_STRES_EEPE_DEM, TP_COMPLETED)
values (4898, 5824143277, 'FX051800030228901_0224051800030228901_00330224_5177', 145815555558935, '0518111130228901_222222224', 1458999999055, '05186465654228901_5555224_5151', '0588888899930228901', 'UOM', null, 'ABOVE ALL INCL', '3655110', 0, 0, '3', 'XENTR', 'NO', 'NO', '6', '6', '6', null, null, null, null, null, 0, null, null, null, null, null, null, null, null, 'ARIX', 'CM', 'BV', '05180', '05180', '23039', '05180', 'X99', 'USD', 'WBRLY', 1, .6, to_date('29-09-2004', 'dd-mm-yyyy'), 1826, to_date('29-09-2007', 'dd-mm-yyyy'), 1, 1, 'PX', 0, 0, 'BX', 'IRIS', '6', null, null, 1, .55, 1, 7, null, 0, null, null, 7, '05180', 'USD', to_date('29-09-2009', 'dd-mm-yyyy'), null, 7, 7, 0, 0, 0, 0, 0, 0, '3', '3', null, 0, 0, 7, 7, 0, to_date('31-10-2013', 'dd-mm-yyyy'), 365, '05181111022890987987987224_AMOVE', 14581544444437234, 0, .54535632249421, 1, 145815, 8935, 12, '45530228901_565656224', 'US', 11, 7, 11, 7, 1, 1, 1, null, 'TYX_55', 'TYX_512', 0, null, '1', 'COM', 1, null, null, 0, 0, 7, 0, 7, 0, 0, 1, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0, null, 7, 0, 7, 0, 7, 7, null, 0, '23039', 'BWOCL', 'TYX_55', 'TYX_512', null, 0, null, null, null, null, null, null, null, null, null, null, null, null, '757880', 1, 0, null, null, null, null, 0, null, null, null, 0, 0, 0);

I hope useful.
Best regards !
J.Z.

[v...@googlecode.com]

Comment #1 on issue 137 by dominiqu...@gmail.com: Memory fault-coredump
unix aix
http://code.google.com/p/vim/issues/detail?id=137

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

[Zulox4]

Hello,
I comment out the line "catch_signals(deathtrap, SIG_ERR);" in os_unix.c and compiled.
Now in dbx i have the stack:
Segmentation fault in extend_brk at 0xd0129178 ($t1)
0xd0129178 (extend_brk+0x238) 90040004 stw r0,0x4(r4)
(dbx) where

libdebug assertion "(framep->getGpr(STKP, &addr) == DB_SUCCESS && *nextStkpp == addr)" failed at line 1299 in file ../../../../../../../../../../../src/bos/usr/ccs/lib/libdbx/libdebug/modules/stackdebug/POWER/stackdb_FrameProgress.C

extend_brk(internal error: assertion failed at line 3550 in file frame.c
??, internal error: assertion failed at line 3550 in file frame.c
??, internal error: assertion failed at line 3550 in file frame.c
??) at 0xd0129178
(dbx)

[Zulox4]

>
> 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
>
>

Hello,

I tested Vim-7.3.1237 (today june/24/2013, the last version), and I don't have any problems with the split. But the completion in : mode and @= normal mode command for tab (completion) key does't work (I tested also on windows and doesn't work), with Vim 7.3.1237. But Shift-tab (back completion) it's working.

Best regards !
Jz

[v...@googlecode.com]

Comment #2 on issue 137 by chrisbr...@googlemail.com: Memory fault-coredump
unix aix
https://code.google.com/p/vim/issues/detail?id=137

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

[v...@googlecode.com]

Comment #3 on issue 137 by Zulolox4...@gmail.com: Memory fault-coredump
unix aix
https://code.google.com/p/vim/issues/detail?id=137

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 !

[v...@googlecode.com]

Comment #4 on issue 137 by Zulolox4...@gmail.com: Memory fault-coredump
unix aix
https://code.google.com/p/vim/issues/detail?id=137

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 !

[v...@googlecode.com]

Updates:
Status: WontFix

Comment #5 on issue 137 by brammool...@gmail.com: Memory fault-coredump
unix aix
https://code.google.com/p/vim/issues/detail?id=137

Closing, since the problem can't be reproduced.