Problem with copy

[Alfredo Braunstein]

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).

The problem is not present in 2.0.6. I got this while trying to
investigate #9302, don't know if it is related though.
A/

==8953== Invalid read of size 1
==8953== at 0x53353B: lyx::(anonymous
namespace)::pasteSelectionHelper(lyx::DocIterator const&,
lyx::ParagraphList const&, std::tr1::shared_ptr<lyx::DocumentClass
const>, lyx::Buffer*, lyx::ErrorList&) (CutAndPaste.cpp:144)
==8953== by 0x538398: lyx::(anonymous
namespace)::putClipboard(lyx::ParagraphList const&,
std::tr1::shared_ptr<lyx::DocumentClass const>,
std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::allocator<wchar_t> > const&) (CutAndPaste.cpp:512)
==8953== by 0x53965D: lyx::cap::copySelection(lyx::Cursor const&,
std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::allocator<wchar_t> > const&) (CutAndPaste.cpp:1007)
==8953== by 0x539724: lyx::cap::copySelection(lyx::Cursor const&)
(CutAndPaste.cpp:908)
==8953== by 0x67A6DB: lyx::Text::dispatch(lyx::Cursor&,
lyx::FuncRequest&) (Text3.cpp:1310)
==8953== by 0x91D230: lyx::InsetText::doDispatch(lyx::Cursor&,
lyx::FuncRequest&) (InsetText.cpp:312)
==8953== by 0x817CCA: lyx::Inset::dispatch(lyx::Cursor&,
lyx::FuncRequest&) (Inset.cpp:319)
==8953== by 0x52AC92: lyx::Cursor::dispatch(lyx::FuncRequest
const&) (Cursor.cpp:399)
==8953== by 0x9778A5:
lyx::frontend::GuiView::dispatchToBufferView(lyx::FuncRequest const&,
lyx::DispatchResult&) (GuiView.cpp:3295)
==8953== by 0x98F670:
lyx::frontend::GuiView::dispatch(lyx::FuncRequest const&,
lyx::DispatchResult&) (GuiView.cpp:3844)
==8953== by 0x95C409:
lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest const&,
lyx::DispatchResult&) (GuiApplication.cpp:1982)
==8953== by 0x94D19E:
lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest const&)
(GuiApplication.cpp:1332)
==8953== Address 0x17cbe996 is 390 bytes inside a block of size 984 free'd

[Richard Heck]

Post by Alfredo Braunstein
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

[Alfredo Braunstein]

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/

Post by Alfredo Braunstein
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

[Cyrille Artho]

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.

Post by Alfredo Braunstein
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/

Post by Alfredo Braunstein
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

[Alfredo Braunstein]

Post by Cyrille Artho
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.

this is about heap-allocated memory that was freed. I would expect a
segfault there, but I read that the free function sometimes avoid
returning memory to the pool for a faster subsequent malloc (i.e. an
optimization of the library).

Post by Cyrille Artho
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.

The valgrind complain is indeed about reading freed memory. It is also
my experience that false positives in valgrind are rare...

A/

[Richard Heck]

Post by Alfredo Braunstein
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...

My problem is that I don't really know how to read the valgrind output.
But from what you've said, my guess would be that the problem is in
putClipboard, in CutAndPaste.cpp. You will see that a static Buffer does
get created there, so you could try modifying the static bit and see if
that helps. The other thing that happens is that this static Buffer gets
cloned, and then the clone is deleted at the end. That might be the
freed memory, but I'm not sure where it would get read.

Richard