Hi Mike! On Mi, 16 Dez 2015, Mike Williams wrote:
> On 16/12/2015 15:28, Dominique Pellé wrote: > >Mike Williams <[email protected]> wrote: > > > >>hg bisect to the rescue! The sort corruption starts with this commit of a > >>one line change: > >> > >>changeset: 4791:65cef998f860 > >>tag: v7.3.1142 > >>user: Bram Moolenaar <[email protected]> > >>date: Fri Jun 07 19:48:39 2013 +0200 > >>files: src/syntax.c src/version.c > >>description: > >>updated for version 7.3.1142 > >>Problem: Memory leak in ":syntime report". > >>Solution: Clear the grow array. (Dominique Pelle) > > > >Hi Mike > > > >This looks strange to me: > >- patch 7.3.1142 looks fine to me at first sight > >- and the code changed in patch 7.3.1142 is not executed > > anyway in the case described by John Beckett. > > > >Can you or someone else double-check the bisection? > >Unfortunately, I still cannot reproduce the bug myself. > > I have checked it through again and it now looks unreliable. Builds > I swear worked ok before now fail when built again, and this is with > clean rebuilds each time. I can't go back that far in VIM history > due to limited compiler support in past years. If nothing else that > would seem to indicate the cause of the issue is not something > recent. > > I have started looking at DrMemory but there is a fair amount of > background noise, not least due to the NFA logs produced with debug > builds. It will take a little while to learn this tool. > > >Maybe someone also has access to proprietary tools > >on Windows like Purify or Insure++. > > Sorry, I don't. Anyone else? For me it seems to be caused by patch 7.3.1141: changeset: 4789:10673b3531eb tag: v7.3.1141 user: Bram Moolenaar <[email protected]> date: Fri Jun 07 19:17:14 2013 +0200 files: src/os_win32.c src/os_win32.h src/version.c description: updated for version 7.3.1141 Problem: Win32: Check for available memory is not reliable and adds overhead. Solution: Remove mch_avail_mem(). (Mike Williams) While I don't know, if it is sensible to remove mch_avail_mem() on windows, I believe this only triggers the bug, because when HAVE_AVAIL_MEM is not set, vim internally sets the 'maxmem' and 'maxmemtot' options to much lower values and I think, high values of those options just hide the bug. (a little bit later), yes, If I run vim 7.4.972 and :set maxmem=1048575 maxmemtot=1048575 (old values since above patch was 2048 for maxmem and 5120 for maxmemtot, before that patch, 1048575 was used) the corruption does not occur. This is probably the reason, the bug does not manifest itself on Linux since there those options are a lot higher by default. So now we need to figure out, what is actually going wrong ;) Best, Christian -- Bevor du das Kind mit dem Bade ausschüttest, sieh nach, ob überhaupt eins drin ist. -- -- 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.
