Loading ...
Sorry, an error occurred while loading the content.
 

SEGV when editing Vim script variables in if_lua

Expand Messages
  • Shougo
    I found the if_lua problem. If I edit Vim script variables in if_lua, Segmentation Fault will occur. ... $ cat foo.vim lua lst = vim.eval( [] ) call
    Message 1 of 7 , Apr 10, 2013
      I found the if_lua problem.
      If I edit Vim script variables in if_lua, Segmentation Fault will occur.

      This is test script:
      ---------------------------------------------------------------
      $ cat foo.vim
      lua lst = vim.eval('[]')
      call garbagecollect()

      $ vim -c 'call feedkeys(repeat(":so foo.vim\<CR>", 10000))'
      SEGV

      This is stack trace:
      ---------------------------------------------------------------
      warning: core file may not match specified executable file.
      [New LWP 18349]
      [New LWP 18351]
      Cannot access memory at address 0x6
      Cannot access memory at address 0x2
      (gdb) bt
      #0 0xb7778424 in ?? ()
      #1 0x0816a859 in get_x11_windis () at os_unix.c:1750
      #2 0x082166eb in netbeans_close () at netbeans.c:192
      #3 0x0812e0be in get_c_indent () at misc1.c:8456
      #4 0x08168c3a in shortmess (x=11) at option.c:11032
      #5 <signal handler called>
      #6 list_free (l=0x772f7e28, recurse=414) at eval.c:5949
      #7 0x080997a5 in list_free (l=0xa717f40, recurse=414) at eval.c:5943
      #8 0x08099843 in listitem_free (item=0xa6ca580) at eval.c:5975
      #9 0x080997a5 in list_free (l=0xa4de290, recurse=414) at eval.c:5943
      #10 0x08099843 in listitem_free (item=0xa49be50) at eval.c:5975
      #11 0x08099774 in list_free (l=0xa4d45ac, recurse=414) at eval.c:5935
      #12 0x08099499 in get_lit_string_tv (arg=0x0, rettv=0x0, evaluate=0) at eval.c:5797
      #13 0x080f7d82 in AppendToRedobuffLit (str=0x3e8 <Address 0x3e8 out of bounds>, len=0) at getchar.c:599
      #14 0x081f5b56 in gui_write (s=0xffffffff <Address 0xffffffff out of bounds>, len=7) at gui.c:1760
      #15 0x081def13 in replace_termcodes (from=0xa341dc1 "", bufp=0x42, from_part=-1, do_lt=23598, special=170362528) at term.c:5210
      #16 0x080f9f3b in vgetorpeek (advance=171187649) at getchar.c:2199
      #17 0x080f9b69 in vgetorpeek (advance=1) at getchar.c:2082
      #18 0x080f7ea8 in stuffReadbuffSpec (s=0x1 <Address 0x1 out of bounds>) at getchar.c:669
      #19 0x080f83dc in ins_typebuf (str=0xbffad2fc "\200\323", <incomplete sequence \372\277>, noremap=-1074081108, offset=52,
      nottyped=136160558, silent=169019552) at getchar.c:954
      #20 0x08140938 in xim_init () at mbyte.c:4921
      #21 0x082163f4 in ruby_vim_init () at if_ruby.c:1347
      #22 0x08215d9e in window_set_cursor (self=1, pos=3220886932) at if_ruby.c:1270
      #23 0xb6a7b935 in ?? ()
      (gdb)

      --
      --
      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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • mattn
      lua is managing vim objects in cache table to release with finalizer. So it doesn t need to call something in luaV_dict_gc/luaV_list_gc to undef vim objects.
      Message 2 of 7 , Apr 10, 2013
        lua is managing vim objects in cache table to release with finalizer. So it doesn't need to call something in luaV_dict_gc/luaV_list_gc to undef vim objects. it makes double free.

        https://gist.github.com/mattn/5356214

        diff -r a079ef0ce001 src/if_lua.c
        --- a/src/if_lua.c Sat Apr 06 17:26:26 2013 +0200
        +++ b/src/if_lua.c Thu Apr 11 01:30:49 2013 +0900
        @@ -665,13 +665,6 @@
        luaV_type_tostring(list, LUAVIM_LIST)

        static int
        -luaV_list_gc (lua_State *L)
        -{
        - list_unref(luaV_unbox(L, luaV_List, 1));
        - return 0;
        -}
        -
        - static int
        luaV_list_len (lua_State *L)
        {
        list_T *l = luaV_unbox(L, luaV_List, 1);
        @@ -801,7 +794,6 @@

        static const luaL_Reg luaV_List_mt[] = {
        {"__tostring", luaV_list_tostring},
        - {"__gc", luaV_list_gc},
        {"__len", luaV_list_len},
        {"__call", luaV_list_call},
        {"__index", luaV_list_index},
        @@ -830,13 +822,6 @@
        luaV_type_tostring(dict, LUAVIM_DICT)

        static int
        -luaV_dict_gc (lua_State *L)
        -{
        - dict_unref(luaV_unbox(L, luaV_Dict, 1));
        - return 0;
        -}
        -
        - static int
        luaV_dict_len (lua_State *L)
        {
        dict_T *d = luaV_unbox(L, luaV_Dict, 1);
        @@ -929,7 +914,6 @@

        static const luaL_Reg luaV_Dict_mt[] = {
        {"__tostring", luaV_dict_tostring},
        - {"__gc", luaV_dict_gc},
        {"__len", luaV_dict_len},
        {"__call", luaV_dict_call},
        {"__index", luaV_dict_index},

        - Yasuhiro Matsumoto

        --
        --
        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 vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Bram Moolenaar
        ... Thanks for the quick response! I have a note in the todo list that test 85, when run with valgrind, finds memory leaks in Lua. Did you every run with Lua
        Message 3 of 7 , Apr 10, 2013
          Yasuhiro Matsumoto wrote:

          > lua is managing vim objects in cache table to release with finalizer.
          > So it doesn't need to call something in luaV_dict_gc/luaV_list_gc to
          > undef vim objects. it makes double free.

          Thanks for the quick response!

          I have a note in the todo list that test 85, when run with valgrind,
          finds memory leaks in Lua. Did you every run with Lua under valgrind?

          --
          Drink wet cement and get really stoned.

          /// Bram Moolenaar -- Bram@... -- 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 vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • mattn
          ... Not yet. Lua works with incremental GC. Some objects which is set undef but not freed remains on memory, i guess. -- -- You received this message from the
          Message 4 of 7 , Apr 10, 2013
            > Did you every run with Lua under valgrind?

            Not yet. Lua works with incremental GC. Some objects which is set undef but not freed remains on memory, i guess.

            --
            --
            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 vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Bram Moolenaar
            ... Is there a call to the Lua library to have it clean up and free all memory? It should be called in lua_end() when EXITFREE is defined. -- We are the Borg
            Message 5 of 7 , Apr 12, 2013
              Yasuhiro Matsumoto wrote:

              > > Did you every run with Lua under valgrind?
              >
              > Not yet. Lua works with incremental GC. Some objects which is set
              > undef but not freed remains on memory, i guess.

              Is there a call to the Lua library to have it clean up and free all
              memory? It should be called in lua_end() when EXITFREE is defined.

              --
              We are the Borg of GNU GPL. We will assimilate your source code.
              Resistance is futile.

              /// Bram Moolenaar -- Bram@... -- 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 vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Yukihiro Nakadaira
              ... I found a few memory leaks in if_lua.c. Please check the attached patch. -- Yukihiro Nakadaira - yukihiro.nakadaira@gmail.com -- -- You received this
              Message 6 of 7 , Apr 12, 2013
                On Thu, Apr 11, 2013 at 6:07 AM, Bram Moolenaar <Bram@...> wrote:

                Yasuhiro Matsumoto wrote:

                > lua is managing vim objects in cache table to release with finalizer.
                > So it doesn't need to call something in luaV_dict_gc/luaV_list_gc to
                > undef vim objects. it makes double free.

                Thanks for the quick response!

                I have a note in the todo list that test 85, when run with valgrind,
                finds memory leaks in Lua.  Did you every run with Lua under valgrind?

                I found a few memory leaks in if_lua.c.
                Please check the attached patch.

                --
                Yukihiro Nakadaira - yukihiro.nakadaira@...

                --
                --
                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 vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
                 
                 
              • Bram Moolenaar
                ... Great, thanks. -- hundred-and-one symptoms of being an internet addict: 158. You get a tuner card so you can watch TV while surfing. /// Bram Moolenaar --
                Message 7 of 7 , Apr 12, 2013
                  Yukihiro Nakadaira wrote:

                  > > I have a note in the todo list that test 85, when run with valgrind,
                  > > finds memory leaks in Lua. Did you every run with Lua under valgrind?
                  > >
                  >
                  > I found a few memory leaks in if_lua.c.
                  > Please check the attached patch.

                  Great, thanks.

                  --
                  hundred-and-one symptoms of being an internet addict:
                  158. You get a tuner card so you can watch TV while surfing.

                  /// Bram Moolenaar -- Bram@... -- 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 vim_dev+unsubscribe@....
                  For more options, visit https://groups.google.com/groups/opt_out.
                Your message has been successfully submitted and would be delivered to recipients shortly.