[GSoC] Copying content from one text box to another in svx/ - A failed attempt
mstahl at redhat.com
Tue Jul 15 01:03:17 PDT 2014
On 15/07/14 03:28, Matteo Campanelli wrote:
> On Mon, Jul 14, 2014 at 5:56 PM, Terrence Enger <tenger at iseries-guru.com
> <mailto:tenger at iseries-guru.com>> wrote:
> The long string of nines looks like the result of reading freed memory
> in a debug build. valgrind may be able to tell you where the memory
> was freed, if you have the patience to wait for it.
yep, something tends to overwrites freed memory with 0x99, at least in
> Valgrind definitely found something kinda directly related to my new
> code; still have to understand what goes wrong at the lowermost call
> though. Some relevant output:
> *==19443== Invalid read of size 8*
> ==19443== at 0xF4339F6: *SdrTextObj::ImpGetDrawOutliner()* const
> ==19443== by 0xF43988B: SdrTextObj::impCopyTextInTextObj(SdrTextObj*)
> const (svdotextdecomposition.cxx:813)
> ==19443== by 0xF4389BF: (anonymous
> const&) (svdotextdecomposition.cxx:587)
> ==19443== by 0xF4387EE: (anonymous
> const&) (svdotextdecomposition.cxx:529)
> [more backtrace...]
> *==19443== Address 0xd8 is not stack'd, malloc'd or (recently) free'd*
> Is 0xd8 the address returned by the lowermost call by any chance
> (i.e. SdrTextObj::ImpGetDrawOutliner())?
it is what is accessed at the position that valgrind reports. i.e.
svdotext.cxx:1233. 0xd8 is usually a null pointer being dereferenced.
also, if you're new to valgrind, you should start your investigation
with the first reported invalid access, usually the later ones are a
consequence of the first (but it may happen that there are some in your
OS libraries, if "suppressions" for those are missing; those can usually
More information about the LibreOffice