On 17/12/2015 15:26, Dominique Pellé wrote:
Mike Williams <mike.willi...@globalgraphics.com> wrote:
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.
There are a lot uninitialised reads but the callstacks are either in the
NFS debug output functions (this is a debug build) or in the keyboard
input handling functions. Nothing which had a sort function in the
callstack :(
But it can also report several other kinds of bugs that can explain
corruptions such as double free, access to uninitialized memory,
buffer overflows, ...
Yep, getting memory and handle leaks but at exit time - IIRC the policy
for VIM is to just drop these all on the floor.
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.
I'll continue using it to get a better handle on how it reports things.
Yell if you'ld like to see the sort of output produced.
TTTFN
Mike
--
Youth would be an ideal state if it came a little later in life.
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
