On 19 March 2016, Dominique Pellé <[email protected]> wrote:
> Hi LCD,
>
> If you can still reproduce this bug, can you check
> whether recent patch 7.4.1592 fixes it?
>
> patch 7.4.1592
> Problem: Quickfix code using memory after being freed. (Dominique Pelle)
> Solution: Detect that the window was closed. (Hirohito Higashi)
(Context moved below the signature)
Hi Dominique,
I think I now have a better understanding of what was going on in my
report. Your patch fixes the crash, but there might still be a deeper
problem with jumping from quickfix lists.
The crash scenario was something like this:
(1) .ll from a loclist
(2) the target file for .ll had a BufEnter autocmd
(3) the BufEnter set a different loclist for the same window
(4) .ll mixed data from the old and new loclists.
Your patch adds a safeguard against the loclist going away from
under .ll's feet, but the fact that an autocmd can happen in the middle
of the operation is still a bug, I think.
/lcd
On 19 March 2016, Dominique Pellé <[email protected]> wrote:
> LCD 47 <[email protected]> wrote:
>
> > On 23 July 2014, Bram Moolenaar <[email protected]> wrote:
> >>
> >> Lcd wrote:
> >>
> >> > > > Scenario:
> >> > > >
> >> > > > (1) set a loclist:
> >> > > >
> >> > > > call setloclist(0, list)
> >> > > >
> >> > > > (2) at some point later replace the list:
> >> > > >
> >> > > > call setloclist(0, other_list, 'r')
> >> > > >
> >> > > > (3) open the quickfix window
> >> > > >
> >> > > > lopen
> >> > > >
> >> > > > (4) switch to the quickfix window and press Enter to jump to an
> >> > > > error:
> >> > > >
> >> > > > .ll
> >> > > >
> >> > > > The result is a read from free'd memory; valgrind trace
> >> > > > included below. It's easy to make Vim crash from there, but the
> >> > > > stack trace doesn't reveal any additional information.
> >> > > >
> >> > > > Sadly, this is not consistently reproducible. I can trigger
> >> > > > it in syntastic, but I can't seem to get the same result in a
> >> > > > simple test file.
> >> > >
> >> > > I have sent out patch 7.4.379. Can you check that this fixes the
> >> > > problem?
> >> >
> >> > That was something I tried too, but it doesn't work; new
> >> > valgrind trace included below.
> >>
> >> What exactly are the arguments to ex_cc when this happens?
> >
> > I added some rudimentary tracing, patch attached. The output is
> > this:
> >
> > ex_cexpr(): arg = "err_lines", nextcmd = "NULL", *cmdlinep = " lgetexpr
> > err_lines", cmdidx = 216, argt = 0x994, skip = 0, forceit = 0, addr_count =
> > 0, line1 = 9, line2 = 9, flags = 0x0, do_ecmd_cmd = "NULL", do_ecmd_lnum =
> > 0, append = 0, usefilter = 0, amount = 0, regname = 0, force_bin = 0,
> > read_edit = 0, force_ff = 0, force_enc = 0, bad_char = 0, useridx = 0
> > get_errorlist()
> > set_errorlist(): action ' ', title = "setloclist()"
> > get_errorlist()
> > get_errorlist()
> > get_errorlist()
> > ex_cc(): arg = "", nextcmd = "NULL", *cmdlinep = ".ll", cmdidx = 220, argt
> > = 0x4503, skip = 0, forceit = 0, addr_count = 1, line1 = 1, line2 = 1,
> > flags = 0x0, do_ecmd_cmd = "NULL", do_ecmd_lnum = 0, append = 0, usefilter
> > = 0, amount = 0, regname = 0, force_bin = 0, read_edit = 0, force_ff = 0,
> > force_enc = 0, bad_char = 0, useridx = 0
> > set_errorlist(): action 'r', title = "setloclist()"
> > get_errorlist()
> > get_errorlist()
> >
> > I'm also attaching the corresponding valgrind log.
> >
> > Perhaps also relevant: steps (1)-(3) happen from a BufWritePost
> > autocmd, step (4) is done after the autocmd has finished.
> >
> >> Without knowing that the number of possibilities is too big.
> >
> > Oh, I do realise it's an useless report. I don't know how to make
> > it more useful. Sorry about that. However the bug appears to be real,
> > which is why I posted all this.
> >
> >> Can you reproduce it with a fixed location list? Otherwise I can't
> >> reproduce the problem.
> > [...]
> >
> > As I said, I can't reproduce the problem in a simpler setup. As any
> > self-respecting Heisenbug, I can't even reproduce it in gdb.
> >
> > /lcd
> >
>
--
--
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.
