Dominique Pelle wrote:

> Elimar Riesebieter <[email protected]> wrote:
> 
> > Hi all,
> >
> > I tried to build v7.4.1444 and got:
> >
> > (1 of 1): Line2^M"test_cdo.res" [New File]^[[64;16H^[[K^[[64;16H[New] 0L, 
> > 0C written^M^M¬
> > Executed 2 tests^M"messages"^[[64;12H^[[K^[[64;12H23L, 
> > 521C^[[64;12H^[[K^[[64;12H28L, 600C written^M^M¬
> > ^[[?1l^[>^[[34h^[[?25h^[[?1049lVIMRUNTIME=../../runtime; export VIMRUNTIME; 
> >  ../vim -f -u unix.vim -U NONE --noplugin --not-a-term -u NONE -U NONE -S 
> > runtest.vim test_channel.vim¬
> > ^[[?1049h^[[?1h^[=^[[1;64r^[[34l^[[34h^[[?25h^[[27m^[[24m^[[23m^[[0m^[[H^[[J^[[?25l^[[64;1H"test_channel.vim"
> >  573 lines, 15676 characters^M^M¬
> > Executing Test_call()^[[34h^[[?25h^M^M¬
> > ^[[?25lExecuting 
> > Test_channel_handler()^[[34h^[[?25h^M^[[?1l^[>^[[?1049lVim: Caught deadly 
> > signal SEGV^M¬
> > ^M¬
> > Vim: Finished.^M¬
> > ^[[64;1HSegmentation fault (core dumped)¬
> > Makefile:130: recipe for target 'test_channel.res' failed¬
> 
> 
> Can you give us a backtrace with gdb?
> You can get it from the core file using:
> 
> $ cd vim/src/testdir
> $ make clean
> $ rm core
> $ make test_channel.res
> (I assume this will crash and create a core file for you)
> $ gdb ../vim core
> (gdb) backtrace
> 
> 
> I tried running that test with valgrind and vim-7.4.1444.
> Valgrind did not detect invalid memory access.

Same for me.  I see that the tests sometimes fail on Travis, looks like
a race condition.  On AppVeyor they either hang or fail.  I did see
something like that on my Windows machine, but not consistently.
I don't yet have a clue what the problem is.

Unfortunately 7.4.1434 was using uninitilazed variables, which I didn't
discover until later.  Some of the patches later may have caused
problems.

> It found
> a leak (with vim compiled with -DEXITFREE) but that
> would not explain the crash. Not sure how to fix that leak:
> 
> ==10305== 16 bytes in 1 blocks are definitely lost in loss record 76 of 363
> ==10305==    at 0x4C2AB80: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==10305==    by 0x4CC3DB: lalloc (misc2.c:920)
> ==10305==    by 0x4CF5B4: alloc_clear (misc2.c:842)
> ==10305==    by 0x5AD141: channel_parse_json (channel.c:1109)
> ==10305==    by 0x5AEA9E: channel_read_json_block (channel.c:1987)
> ==10305==    by 0x43B617: common_channel_read (eval.c:10468)

I think this can be fixed by freeing the list that
channel_read_json_block() returns.  The contents are copied to rettv but
listtv itself is not freed.

-- 
LETTERS TO THE EDITOR (The Times of London)

Dear Sir,

I am firmly opposed to the spread of microchips either to the home or
to the office.  We have more than enough of them foisted upon us in
public places.  They are a disgusting Americanism, and can only result
in the farmers being forced to grow smaller potatoes, which in turn
will cause massive unemployment in the already severely depressed
agricultural industry.

Yours faithfully,
        Capt. Quinton D'Arcy, J. P.
        Sevenoaks

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

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

Raspunde prin e-mail lui