Re: [GSoC] Copying content from one text box to another in svx/ - A failed attempt

On 15/07/14 03:28, Matteo Campanelli wrote:
> On Mon, Jul 14, 2014 at 5:56 PM, Terrence Enger <tenger@iseries-guru.com
> <mailto:tenger@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
--enable-dbgutil builds.

> 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
> (svdotext.cxx:1233)
> ==19443==    by 0xF43988B: SdrTextObj::impCopyTextInTextObj(SdrTextObj*)
> const (svdotextdecomposition.cxx:813)
> ==19443==    by 0xF4389BF: (anonymous
> namespace)::impTextBreakupHandler::impHandleTruncatedPortion(DrawPortionInfo
> const&) (svdotextdecomposition.cxx:587)
> ==19443==    by 0xF4387EE: (anonymous
> namespace)::impTextBreakupHandler::impHandleDrawPortionInfo(DrawPortionInfo
> 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
be ignored...).