Dominique Pellé wrote:
> Bram Moolenaar wrote:
>
>> Dominique Pelle wrote:
....
>>> (2) In vim/src/undo.c I see at line 92:
>>>
>>> 91 /* See below: use malloc()/free() for memory management. */
>>> 92 #define U_USE_MALLOC 1
>>>
>>> Whether U_USE_MALLOC is defined or not selects different
>>> implementations of U_FREE_LINE and U_ALLOC_LINE.
>>>
>>> Is the implementation when U_USE_MALLOC is undefined
>>> still meant to be used? Or can it be removed?
>>>
>>> I'm asking because if I comment out the line #define U_USE_MALLOC 1
>>> at line undo.c:92, then Vim quickly crashes when using persistent-undo.
>>> In other words, persistent undo only works when U_USE_MALLOC is defined.
>>
>> Can you see why it crashes? Perhaps it allocates a block that is too
>> big?
>
> If I just recompile Vim with "#define U_USE_MALLOC 1" commented out
> (without any patch) as follows:
>
> /* See below: use malloc()/free() for memory management. */
> /*#define U_USE_MALLOC 1*/
>
> Then the following command is enough to make Vim crash:
>
> $ vim -u NONE --noplugin -c 'wundo! foo' -c 'rundo foo'
> Vim: Caught deadly signal SEGV
> Vim: Finished.
> Segmentation fault
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x081bf48c in u_free_line (ptr=0x8264f90 "", keep=0) at undo.c:2846
> 2846 if ((nextb = curbuf->b_mb_current->mb_next) != NULL
> (gdb) bt
> #0 0x081bf48c in u_free_line (ptr=0x8264f90 "", keep=0) at undo.c:2846
> #1 0x081bc5f0 in u_read_undo (name=0x8264e06 "foo",
> hash=0xbfffed9c
> "\343\260\304B\230\374\034\024\232\373\364\310\231o\271$'\256A\344d\233\223L\244\225\231\033xR\270U")
> at undo.c:1094
> #2 0x080afc34 in ex_rundo (eap=0xbfffedfc) at ex_docmd.c:8481
> #3 0x080a70dd in do_one_cmd (cmdlinep=0xbfffefb0, sourcing=1,
> cstack=0xbfffefb8, fgetline=0,
> cookie=0x0) at ex_docmd.c:2639
> #4 0x080a49b6 in do_cmdline (cmdline=0xbffff6a3 "rundo foo",
> getline=0, cookie=0x0, flags=11)
> at ex_docmd.c:1108
> #5 0x080a4070 in do_cmdline_cmd (cmd=0xbffff6a3 "rundo foo") at
> ex_docmd.c:714
> #6 0x080e935d in exe_commands (parmp=0xbffff364) at main.c:2750
> #7 0x080e6b3a in main (argc=8, argv=0xbffff4e4) at main.c:880
> (gdb) list
> 2841 if (curbuf->b_mb_current == NULL || mp < (minfo_T
> *)curbuf->b_mb_current)
> 2842 {
> 2843 curbuf->b_mb_current = curbuf->b_block_head.mb_next;
> 2844 curbuf->b_m_search = NULL;
> 2845 }
> 2846 if ((nextb = curbuf->b_mb_current->mb_next) != NULL
> 2847 && (minfo_T
> *)nextb < mp)
> 2848 {
> 2849 curbuf->b_mb_current = nextb;
> 2850 curbuf->b_m_search = NULL;
>
> (gdb) p curbuf
> $1 = (buf_T *) 0x8234dd0
> (gdb) p curbuf->b_mb_current
> $2 = (mblock_T *) 0x0
>
> So accessing curbuf->b_mb_current->mb_next dereferences NULL.
>
> I have not had time to look at how u_alloc_line() and u_free_line()
> work. Using vim_malloc() and vim_free() is certainly simpler. malloc()
> and free() are also quite optimized. So I don't see the need
> for a special implementation.
I now understand why vim-7.3a crashes when undefining line
#define U_USE_MALLOC 1 in "undo.c".
u_alloc_line() and u_free_line(), which are used when
U_USE_MALLOC is undefined, use buffers inside 'curbuf'.
All allocations make during in u_read_undo() gets freed
when calling "u_blockfree(curbuf);".
Attached patch makes it work I think (I did not test in details)
by calling u_blockfree(curbuf) earlier (before any call to U_ALLOC_LINE())
in u_read_undo().
However, I DON'T THINK IT'S A GOOD IDEA TO APPLY THIS PATCH
anyway since if an error happens while loading the persistent undo file,
the current undo information would be lost!
It's best and a lot simpler to just remove all code in
#define U_USE_MALLOC which is not currently used anyway
and no longer valid.
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
