Mike Williams <[email protected]> wrote: > On 17/12/2015 10:50, JohnBeckett wrote: >> >> Mike Williams: >>> >>> I'll look some more into it to make the defaults on Windows >>> more sensible and if the code can be simplified. >> >> >> Thanks all for the interesting progress. I'm trying to set up a test >> system where I might be able to join in but it's a long time since I worked >> in C. I don't know anything about the HAVE_xxx settings, but it appears >> there is a condition where Vim's data can be corrupted and that condition is >> being exposed by the particular tests being run. However, the problem is >> potentially more general, and conceivably corruptions could occur in other >> circumstances. > > > While paranoia is good in development in this case I think the simplest > thing to say is that there seems to be corruption when using sort with low > max mem settings. Starting from there we'll see what any investigation > shows up. At least for now the workaround is to set maxmem values larger > than the default. > >> Have you reached a conclusion about whether the problem is related to a >> compiler optimisation bug? My guess would be that it is not since I don't >> think Steve Hall uses Visual Studio to build the Vim-without-Cream that I >> mentioned, and it also shows the corruption. > > > It is not a compiler optimisation bug. I can reproduce the issue on linux > if I limit maxmem to 2048 and maxmemtot to 5120, the current Windows default > values for these options. It is not Windows and/or compiler settings > specific.
I still can't reproduce the issue on Linux x86_64, even after setting maxmem to 2048 and maxmemtot to 5120 as suggested. >> There has to be a clue in the fact that I have only ever seen corrupted >> text after executing :sort. Presumably Vim makes an array of pointers and >> sorts them. That array is being clobbered, or Vim's pointer to the array is >> being overwritten. Are any unchecked memory allocations done in Vim's sort? > > > That is a good initial working theory. The maxmem setting will cause VIM to > recover memory and off the cuff it sounds like this is leaving dangling > pointers which are then being used and just so happen to keep pointing to > allocated memory so we don't see a crash, just random data. I see no corruption and no errors reported by valgrind either. Yet, there must be a bug since several people can see it. If someone can reproduce it on Linux, then use valgrind to tell what's wrong. Regards Dominique -- -- 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.
