Mike Williams <[email protected]> wrote: > On 17/12/2015 12:30, Dominique Pellé wrote: >>> >>> 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. > > > I reproduced by setting these settings first, before following the rest of > John's process for reproducing the corruption. This is on 32bit Ubuntu > 12.04, currently I don't have access to a 64bit unix to check for any > difference. > >> 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. > > > Out of interest what would you hope valgrind to report to indicate it can > see a problem? Should DrMemory be able to spot the issue?
I suspect that in that case it would indicate access to freed memory with stack where it's detected and stack where memory was previously freed. But it can also report several other kinds of bugs that can explain corruptions such as double free, access to uninitialized memory, buffer overflows, ... I'll try with 32-bits Linux later too. > Should DrMemory be able to spot the issue? Probably, but I have not used it myself. 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.
