On 15/07/14 03:28, Matteo Campanelli wrote: > > On Mon, Jul 14, 2014 at 5:56 PM, Terrence Enger <ten...@iseries-guru.com > <mailto:ten...@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...). _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
