Bram Moolenaar wrote: > Patch 7.4.402 > Problem: Test 72 crashes under certain conditions. (Kazunobu Kuriyama) > Solution: Clear the whole bufinfo_T early. > Files: src/undo.c
Test 72 no longer segfaults after this patch. However, running it under valgrind shows access to uninitialized memory: ==19752== Memcheck, a memory error detector ==19752== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==19752== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info ==19752== Command: ../vim -u unix.vim -U NONE --noplugin -s dotest.in test72.in ==19752== Parent PID: 19751 ==19752== ==19752== Use of uninitialised value of size 8 ==19752== at 0x4104E9: bf_e_block (blowfish.c:360) ==19752== by 0x410D1B: bf_e_cblock (blowfish.c:396) ==19752== by 0x41147A: crypt_blowfish_encode (blowfish.c:618) ==19752== by 0x41517B: crypt_encode (crypt.c:448) ==19752== by 0x4C127D: ml_encrypt_data (memline.c:4841) ==19752== by 0x5DE3AA: mf_write_block (memfile.c:1138) ==19752== by 0x5DE2AC: mf_write (memfile.c:1094) ==19752== by 0x5DD8E7: mf_sync (memfile.c:592) ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282) ==19752== by 0x4A0CE1: updatescript (getchar.c:1581) ==19752== by 0x4A04C1: gotchars (getchar.c:1284) ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424) ==19752== by 0x4A0DAA: vgetc (getchar.c:1637) ==19752== by 0x42573D: insertchar (edit.c:6051) ==19752== by 0x42528E: insert_special (edit.c:5832) ... many more errors... ==19752== Syscall param write(buf) points to uninitialised byte(s) ==19752== at 0x662C040: __write_nocancel (syscall-template.S:82) ==19752== by 0x498B7D: write_eintr (fileio.c:10433) ==19752== by 0x5DE3D4: mf_write_block (memfile.c:1144) ==19752== by 0x5DE2AC: mf_write (memfile.c:1094) ==19752== by 0x5DD8E7: mf_sync (memfile.c:592) ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282) ==19752== by 0x4A0CE1: updatescript (getchar.c:1581) ==19752== by 0x4A04C1: gotchars (getchar.c:1284) ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424) ==19752== by 0x4A0DAA: vgetc (getchar.c:1637) ==19752== by 0x42573D: insertchar (edit.c:6051) ==19752== by 0x42528E: insert_special (edit.c:5832) ==19752== by 0x41D9F3: edit (edit.c:1494) ==19752== by 0x4FEA0C: invoke_edit (normal.c:9062) ==19752== by 0x4FE9A5: nv_edit (normal.c:9035) ==19752== Address 0x76f0510 is 4,080 bytes inside a block of size 4,096 alloc'd ==19752== at 0x4C2C857: malloc (vg_replace_malloc.c:291) ==19752== by 0x4DFEDA: lalloc (misc2.c:921) ==19752== by 0x4DFDE7: alloc (misc2.c:820) ==19752== by 0x4C11C0: ml_encrypt_data (memline.c:4829) ==19752== by 0x5DE3AA: mf_write_block (memfile.c:1138) ==19752== by 0x5DE2AC: mf_write (memfile.c:1094) ==19752== by 0x5DD8E7: mf_sync (memfile.c:592) ==19752== by 0x4BC8D0: ml_sync_all (memline.c:2282) ==19752== by 0x4A0CE1: updatescript (getchar.c:1581) ==19752== by 0x4A04C1: gotchars (getchar.c:1284) ==19752== by 0x4A1DD9: vgetorpeek (getchar.c:2424) ==19752== by 0x4A0DAA: vgetc (getchar.c:1637) ==19752== by 0x42573D: insertchar (edit.c:6051) ==19752== by 0x42528E: insert_special (edit.c:5832) ==19752== by 0x41D9F3: edit (edit.c:1494) I assume it is a bug. In some rare cases, reading uninitialized memory can be one source of randomness. If that was the case, it would be good to indicate it in a comment. But more likely it's a bug. Regards Dominique -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
