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

Re: Patch 7.3.799

Expand Messages
  • Ben Fritz
    ... Probably it s too late, but I only contributed to the discussion. John Szakmeister was the original reporter of the issue. -- -- You received this message
    Message 1 of 10 , Feb 6, 2013
    • 0 Attachment
      On Wednesday, February 6, 2013 5:15:41 AM UTC-6, Bram Moolenaar wrote:
      > Patch 7.3.799
      >
      > Problem: The color column is not correct when entering a buffer. (Ben
      >
      > Fritz)
      >
      > Solution: Call check_colorcolumn() if 'textwidth' changed. (Christian
      >
      > Brabandt)
      >

      Probably it's too late, but I only contributed to the discussion. John Szakmeister was the original reporter of the issue.

      --
      --
      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.
    • Tony Mechelynck
      ... [...] I get the following warning in tiny build but not in huge build: gcc -c -I. -Iproto -DHAVE_CONFIG_H -I/usr/local/include -O2
      Message 2 of 10 , Feb 6, 2013
      • 0 Attachment
        On 06/02/13 12:15, Bram Moolenaar wrote:
        >
        > Patch 7.3.799
        > Problem: The color column is not correct when entering a buffer. (Ben
        > Fritz)
        > Solution: Call check_colorcolumn() if 'textwidth' changed. (Christian
        > Brabandt)
        > Files: src/buffer.c
        [...]

        I get the following warning in "tiny" build but not in "huge" build:

        gcc -c -I. -Iproto -DHAVE_CONFIG_H -I/usr/local/include -O2
        -fno-strength-reduce -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
        -o objects/buffer.o buffer.c
        buffer.c: In function ‘enter_buffer’:
        buffer.c:1444:10: warning: unused variable ‘old_tw’ [-Wunused-variable]

        Build is successful (this is a warning, not an error).


        Best regards,
        Tony.
        --
        Every program has two purposes -- one for which it was written and
        another for which it wasn't.

        --
        --
        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
        ... Ah, we forgot an #ifdef. I ll fix it. -- ROBIN: (warily) And if you get a question wrong? ARTHUR: You are cast into the Gorge of Eternal Peril. ROBIN:
        Message 3 of 10 , Feb 6, 2013
        • 0 Attachment
          Tony Mechelynck wrote:

          > On 06/02/13 12:15, Bram Moolenaar wrote:
          > >
          > > Patch 7.3.799
          > > Problem: The color column is not correct when entering a buffer. (Ben
          > > Fritz)
          > > Solution: Call check_colorcolumn() if 'textwidth' changed. (Christian
          > > Brabandt)
          > > Files: src/buffer.c
          > [...]
          >
          > I get the following warning in "tiny" build but not in "huge" build:
          >
          > gcc -c -I. -Iproto -DHAVE_CONFIG_H -I/usr/local/include -O2
          > -fno-strength-reduce -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
          > -o objects/buffer.o buffer.c
          > buffer.c: In function ‘enter_buffer’:
          > buffer.c:1444:10: warning: unused variable ‘old_tw’ [-Wunused-variable]
          >
          > Build is successful (this is a warning, not an error).

          Ah, we forgot an #ifdef. I'll fix it.

          --
          ROBIN: (warily) And if you get a question wrong?
          ARTHUR: You are cast into the Gorge of Eternal Peril.
          ROBIN: Oh ... wacho!
          "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

          /// 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.
        • Christian Brabandt
          Hi Bram! ... This segfaults for me at Test 87 in test49.vim This patch fixes it: diff --git a/src/buffer.c b/src/buffer.c ... +++ b/src/buffer.c @@ -1442,7
          Message 4 of 10 , Feb 13, 2013
          • 0 Attachment
            Hi Bram!

            On Mi, 06 Feb 2013, Bram Moolenaar wrote:

            >
            > Patch 7.3.799
            > Problem: The color column is not correct when entering a buffer. (Ben
            > Fritz)
            > Solution: Call check_colorcolumn() if 'textwidth' changed. (Christian
            > Brabandt)
            > Files: src/buffer.c

            This segfaults for me at Test 87 in test49.vim This patch fixes it:

            diff --git a/src/buffer.c b/src/buffer.c
            --- a/src/buffer.c
            +++ b/src/buffer.c
            @@ -1442,7 +1442,7 @@
            buf_T *buf;
            {
            #ifdef FEAT_SYN_HL
            - long old_tw = curbuf->b_p_tw;
            + long old_tw = buf_valid(curbuf) ? curbuf->b_p_tw : 0;
            #endif

            /* Copy buffer and window local option values. Not for a help buffer. */


            regards,
            Christian
            --
            Ein liebes Wort hat oft die Macht, ein Wunder zu vollbringen; es
            bringt aus Leid und dunkler Nacht ein Menschenherz zum Klingen.
            -- Fischer-Friesenhausen

            --
            --
            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
            ... Any idea why it crashes for you and not for me? Perhaps should run under valgrind. -- ARTHUR: CHARGE! [The mighty ARMY charges. Thundering noise of feet.
            Message 5 of 10 , Feb 14, 2013
            • 0 Attachment
              Christian Brabandt wrote:

              > Hi Bram!
              >
              > On Mi, 06 Feb 2013, Bram Moolenaar wrote:
              >
              > >
              > > Patch 7.3.799
              > > Problem: The color column is not correct when entering a buffer. (Ben
              > > Fritz)
              > > Solution: Call check_colorcolumn() if 'textwidth' changed. (Christian
              > > Brabandt)
              > > Files: src/buffer.c
              >
              > This segfaults for me at Test 87 in test49.vim This patch fixes it:
              >
              > diff --git a/src/buffer.c b/src/buffer.c
              > --- a/src/buffer.c
              > +++ b/src/buffer.c
              > @@ -1442,7 +1442,7 @@
              > buf_T *buf;
              > {
              > #ifdef FEAT_SYN_HL
              > - long old_tw = curbuf->b_p_tw;
              > + long old_tw = buf_valid(curbuf) ? curbuf->b_p_tw : 0;
              > #endif
              >
              > /* Copy buffer and window local option values. Not for a help buffer. */

              Any idea why it crashes for you and not for me?
              Perhaps should run under valgrind.

              --
              ARTHUR: CHARGE!
              [The mighty ARMY charges. Thundering noise of feet. Clatter of coconuts.
              Shouts etc. Suddenly there is a wail of a siren and a couple of police
              cars roar round in front of the charging ARMY and the POLICE leap out and
              stop them. TWO POLICEMAN and the HISTORIAN'S WIFE. Black Marias skid up
              behind them.]
              HISTORIAN'S WIFE: They're the ones, I'm sure.
              "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

              /// 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.
            • Christian Brabandt
              Hi Bram! ... No and it doesn t segfault, if I only let test87 run. Problem is, close_buffer() might close curbuf and curbuf can get freed(). Of course then you
              Message 6 of 10 , Feb 14, 2013
              • 0 Attachment
                Hi Bram!

                On Do, 14 Feb 2013, Bram Moolenaar wrote:

                > Any idea why it crashes for you and not for me?
                > Perhaps should run under valgrind.

                No and it doesn't segfault, if I only let test87 run. Problem is,
                close_buffer() might close curbuf and curbuf can get freed(). Of course
                then you can't access curbuf->b_p_tw in enter_buffer() anymore.

                Valgrind confirms this:

                ==12456== Memcheck, a memory error detector
                ==12456== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
                ==12456== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
                ==12456== Command: ../vim -u unix.vim -U NONE --noplugin -s dotest.in test49.in
                ==12456== Parent PID: 12450
                ==12456==
                ==12456== Invalid read of size 8
                ==12456== at 0x40FB67: enter_buffer (buffer.c:1445)
                ==12456== by 0x40FB51: set_curbuf (buffer.c:1433)
                ==12456== by 0x40F8FC: do_buffer (buffer.c:1330)
                ==12456== by 0x40ED18: do_bufdel (buffer.c:872)
                ==12456== by 0x472768: ex_bunload (ex_docmd.c:5062)
                ==12456== by 0x46DE03: do_one_cmd (ex_docmd.c:2681)
                ==12456== by 0x46B3EF: do_cmdline (ex_docmd.c:1122)
                ==12456== by 0x454E8C: call_user_func (eval.c:22604)
                ==12456== by 0x43DB87: call_func (eval.c:8484)
                ==12456== by 0x43D73C: get_func_tv (eval.c:8326)
                ==12456== by 0x43905E: eval7 (eval.c:5160)
                ==12456== by 0x4388F7: eval6 (eval.c:4812)
                ==12456== by 0x438447: eval5 (eval.c:4628)
                ==12456== by 0x43774E: eval4 (eval.c:4321)
                ==12456== by 0x437592: eval3 (eval.c:4233)
                ==12456== Address 0xc68b550 is 5,360 bytes inside a block of size 7,064 free'd
                ==12456== at 0x4C2A739: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
                ==12456== by 0x4DD924: vim_free (misc2.c:1744)
                ==12456== by 0x40E983: free_buffer (buffer.c:665)
                ==12456== by 0x40E5F0: close_buffer (buffer.c:499)
                ==12456== by 0x40FAE8: set_curbuf (buffer.c:1409)
                ==12456== by 0x40F8FC: do_buffer (buffer.c:1330)
                ==12456== by 0x40ED18: do_bufdel (buffer.c:872)
                ==12456== by 0x472768: ex_bunload (ex_docmd.c:5062)
                ==12456== by 0x46DE03: do_one_cmd (ex_docmd.c:2681)
                ==12456== by 0x46B3EF: do_cmdline (ex_docmd.c:1122)
                ==12456== by 0x454E8C: call_user_func (eval.c:22604)
                ==12456== by 0x43DB87: call_func (eval.c:8484)
                ==12456== by 0x43D73C: get_func_tv (eval.c:8326)
                ==12456== by 0x43905E: eval7 (eval.c:5160)
                ==12456== by 0x4388F7: eval6 (eval.c:4812)
                ==12456==

                regards,
                Christian
                --
                Der Fortschritt geschieht heute so schnell, daß, während jemand eine
                Sache für gänzlich undurchführbar erklärt, er von einem anderen
                unterbrochen wird, der sie schon realisiert hat.
                -- Albert Einstein

                --
                --
                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
                ... I think we should actually move the code to get the old value of textwidth to the caller of enter_buffer(). It might be that there are only one or two
                Message 7 of 10 , Feb 14, 2013
                • 0 Attachment
                  Christian Brabandt wrote:

                  > Hi Bram!
                  >
                  > On Do, 14 Feb 2013, Bram Moolenaar wrote:
                  >
                  > > Any idea why it crashes for you and not for me?
                  > > Perhaps should run under valgrind.
                  >
                  > No and it doesn't segfault, if I only let test87 run. Problem is,
                  > close_buffer() might close curbuf and curbuf can get freed(). Of course
                  > then you can't access curbuf->b_p_tw in enter_buffer() anymore.
                  >
                  > Valgrind confirms this:
                  >
                  > ==12456== Memcheck, a memory error detector
                  > ==12456== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
                  > ==12456== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
                  > ==12456== Command: ../vim -u unix.vim -U NONE --noplugin -s dotest.in test49.in
                  > ==12456== Parent PID: 12450
                  > ==12456==
                  > ==12456== Invalid read of size 8
                  > ==12456== at 0x40FB67: enter_buffer (buffer.c:1445)
                  > ==12456== by 0x40FB51: set_curbuf (buffer.c:1433)
                  > ==12456== by 0x40F8FC: do_buffer (buffer.c:1330)
                  > ==12456== by 0x40ED18: do_bufdel (buffer.c:872)
                  > ==12456== by 0x472768: ex_bunload (ex_docmd.c:5062)
                  > ==12456== by 0x46DE03: do_one_cmd (ex_docmd.c:2681)
                  > ==12456== by 0x46B3EF: do_cmdline (ex_docmd.c:1122)
                  > ==12456== by 0x454E8C: call_user_func (eval.c:22604)
                  > ==12456== by 0x43DB87: call_func (eval.c:8484)
                  > ==12456== by 0x43D73C: get_func_tv (eval.c:8326)
                  > ==12456== by 0x43905E: eval7 (eval.c:5160)
                  > ==12456== by 0x4388F7: eval6 (eval.c:4812)
                  > ==12456== by 0x438447: eval5 (eval.c:4628)
                  > ==12456== by 0x43774E: eval4 (eval.c:4321)
                  > ==12456== by 0x437592: eval3 (eval.c:4233)
                  > ==12456== Address 0xc68b550 is 5,360 bytes inside a block of size 7,064 free'd
                  > ==12456== at 0x4C2A739: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
                  > ==12456== by 0x4DD924: vim_free (misc2.c:1744)
                  > ==12456== by 0x40E983: free_buffer (buffer.c:665)
                  > ==12456== by 0x40E5F0: close_buffer (buffer.c:499)
                  > ==12456== by 0x40FAE8: set_curbuf (buffer.c:1409)
                  > ==12456== by 0x40F8FC: do_buffer (buffer.c:1330)
                  > ==12456== by 0x40ED18: do_bufdel (buffer.c:872)
                  > ==12456== by 0x472768: ex_bunload (ex_docmd.c:5062)
                  > ==12456== by 0x46DE03: do_one_cmd (ex_docmd.c:2681)
                  > ==12456== by 0x46B3EF: do_cmdline (ex_docmd.c:1122)
                  > ==12456== by 0x454E8C: call_user_func (eval.c:22604)
                  > ==12456== by 0x43DB87: call_func (eval.c:8484)
                  > ==12456== by 0x43D73C: get_func_tv (eval.c:8326)
                  > ==12456== by 0x43905E: eval7 (eval.c:5160)
                  > ==12456== by 0x4388F7: eval6 (eval.c:4812)
                  > ==12456==

                  I think we should actually move the code to get the old value of
                  'textwidth' to the caller of enter_buffer(). It might be that there are
                  only one or two places where this is relevant. Perhaps it can be
                  combined with some other option value that might have changed and
                  require an action after entering another buffer?

                  --
                  "I love deadlines. I especially like the whooshing sound they
                  make as they go flying by."
                  -- Douglas Adams

                  /// 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.
                • Christian Brabandt
                  Hi Bram! ... Here is a patch ... Not sure which ones need to be taken care of. regards, Christian -- Phantasie ist etwas, das sich viele gar nicht vorstellen
                  Message 8 of 10 , Feb 15, 2013
                  • 0 Attachment
                    Hi Bram!

                    On Do, 14 Feb 2013, Bram Moolenaar wrote:

                    > I think we should actually move the code to get the old value of
                    > 'textwidth' to the caller of enter_buffer(). It might be that there are
                    > only one or two places where this is relevant.

                    Here is a patch

                    > Perhaps it can be combined with some other option value that might
                    > have changed and require an action after entering another buffer?

                    Not sure which ones need to be taken care of.

                    regards,
                    Christian
                    --
                    Phantasie ist etwas, das sich viele gar nicht vorstellen können.
                    -- Helmut Qualtinger

                    --
                    --
                    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! ... Never mind then. -- To keep milk from turning sour: Keep it in the cow. /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net
                    Message 9 of 10 , Feb 15, 2013
                    • 0 Attachment
                      Christian Brabandt wrote:

                      > Hi Bram!
                      >
                      > On Do, 14 Feb 2013, Bram Moolenaar wrote:
                      >
                      > > I think we should actually move the code to get the old value of
                      > > 'textwidth' to the caller of enter_buffer(). It might be that there are
                      > > only one or two places where this is relevant.
                      >
                      > Here is a patch

                      Thanks!

                      > > Perhaps it can be combined with some other option value that might
                      > > have changed and require an action after entering another buffer?
                      >
                      > Not sure which ones need to be taken care of.

                      Never mind then.

                      --
                      To keep milk from turning sour: Keep it in the cow.

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