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

classic Classic list List threaded Threaded
5 messages Options
Matteo Campanelli Matteo Campanelli
Reply | Threaded
Open this post in threaded view
|

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

Today I tried to embed some code to link the content of one text box to another in Draw. I took heavy inspiration from some existing code in SdrTextObj::FitFrameToTextSize(). However I get a SIGSEGV in some other part of the code shortly afterwards.

What I tried to do was the following:
- Having two text boxes in the document,
- I tried to copy (a part of) the content from SdrPage::GetObj(0) into SdrPage::GetObj(1). This occurs in svx's drawinglayer and in particular in impTextBreakupHandler.
- The text is copied into the outliner of the second text box to be layouted again (simulating what FitFrameToTextSize above does. An important difference with that code is that now two different boxes are used).

This is the link to the main commit: 


Here is the seg. fault message:
Program received signal SIGSEGV, Segmentation fault.
0x00007f5cb26d9b5c in ContentAttribs::GetItem (this=0x99999999999999a1, nWhich=4006)
    at /home/seriouspillow/Proiects/libreoffice/gsoc/core/editeng/source/editeng/editdoc.cxx:1804
1804    if ( pStyle && ( aAttribSet.GetItemState( nWhich, false ) != SFX_ITEM_ON  ) )


Thorsten, any opinions?

Cheers,
Matteo


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Terrence Enger Terrence Enger
Reply | Threaded
Open this post in threaded view
|

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

On Mon, 2014-07-14 at 16:51 +0200, Matteo Campanelli wrote:
>
> Here is the seg. fault message:
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007f5cb26d9b5c in ContentAttribs::GetItem (this=0x99999999999999a1,
> nWhich=4006)
>     at
> /home/seriouspillow/Proiects/libreoffice/gsoc/core/editeng/source/editeng/editdoc.cxx:1804
> 1804    if ( pStyle && ( aAttribSet.GetItemState( nWhich, false ) !=
> SFX_ITEM_ON  ) )

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.

HTH,
Terry.


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Matteo Campanelli Matteo Campanelli
Reply | Threaded
Open this post in threaded view
|

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




On Mon, Jul 14, 2014 at 5:56 PM, Terrence Enger <[hidden email]> 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.

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
==19443== 
==19443== 
==19443== Process terminating with default action of signal 11 (SIGSEGV)
==19443==  Access not within mapped region at address 0xD8
==19443==    at 0xF4339F6: SdrTextObj::ImpGetDrawOutliner() const (svdotext.cxx:1233)
==19443==    by 0xF43988B: SdrTextObj::impCopyTextInTextObj(SdrTextObj*) const (svdotextdecomposition.cxx:813)
[more backtrace...]

Is 0xd8 the address returned by the lowermost call by any chance (i.e. SdrTextObj::ImpGetDrawOutliner())?

Matteo


HTH,
Terry.




_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Stahl-2 Michael Stahl-2
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]
> <mailto:[hidden email]>> 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

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

On 07/15/2014 10:03 AM, Michael Stahl wrote:
> On 15/07/14 03:28, Matteo Campanelli 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.

That would be ooenv's

   export MALLOC_PERTURB_=153

(unless you configure --disable-ooenv).

Stephan
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice