In my experience, false positives regarding uninitialized memory are
extremely rare. So it's most likely a real problem. Maybe the code refers
to stack-allocated memory or heap memory that was used just before, so the
data is still "in the right place" under normal cases? This could be the
reason why no crash has been observed with this code so far.
Normally, reading data that is considered "uninitialized" by valgrind could
also read data that has recently been freed; AFAIK the error message is the
same. However, such code tends to work by coincidence rather than by design.
Alfredo Braunstein wrote:
Unless it's a false positive by valgrind, then we are reading junk
from memory and more sooner than later we will have problems. Moreover, it
makes investigating other issues harder., so IMHO is that it is worth
lookin into. Unfortunately, I know little about that part of the
code...
A/
On Mon, Oct 20, 2014 at 9:08 PM, Richard Heck <rgh...@lyx.org> wrote:
On 10/20/2014 01:25 PM, Alfredo Braunstein wrote:
Running under valgrind, open LyX (master branch), create a new
document, write 'a', select it and copy it; valgrind complains (see
below). I get it consistently.
A second copy doesn't give any problem, it's just the first one that
does. The problem seems related to a badly initialized temporary
buffer (maybe).
This is possible. I believe a temporary Buffer is created in this case to
allow, e.g.,
XHTML to be put on the clipboard. That Buffer is then re-used later. I'm not
sure why
valgrind is complaining, though. Maybe we don't initialize certain things
because, in
this case, we don't actually need to do so?
Richard
--
Regards,
Cyrille Artho - http://artho.com/
Better once than never, for never too late.
-- Shakespeare, "The Taming of the Shrew"
