Bug 40195 - crash using introspection on createTextCursorByRange use
Summary: crash using introspection on createTextCursorByRange use
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: Other All
: medium critical
Assignee: Cédric Bosdonnat
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-18 03:50 UTC by Laurent Godard
Modified: 2011-12-19 08:07 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
the sample containing a table and the nthe macro to be run (10.07 KB, application/vnd.oasis.opendocument.text)
2011-08-18 03:50 UTC, Laurent Godard
Details
crash stack trace (63.68 KB, text/x-log)
2011-08-18 05:52 UTC, Laurent Godard
Details
maybe patch (676 bytes, patch)
2011-08-22 04:56 UTC, Noel Power
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent Godard 2011-08-18 03:50:07 UTC
Created attachment 50347 [details]
the sample containing a table and the nthe macro to be run

a writer document, containing a table
a textCursor is obtain from table.anchor

when watching the cursor properties in basic IDE or using XRay, LibrO crashes

see attachment for a sample document containing a macro
set a break point on the print statement ans explore the cursor in the IDE

here, the macro


Sub Main

	doc = thisComponent
	table = doc.textTables(0)

	' the offending cursor
	cursor = doc.text.createTextCursorByRange(table.anchor)
		
	' this 2 following cases are ok
	'	cursor = doc.text.createTextCursor()		
	'	cursor = doc.text.createTextCursorByrange(doc.text.end)
		
	print "set a break point on this line and watch the cursor"

End Sub
Comment 1 Laurent Godard 2011-08-18 04:04:55 UTC
reproduced on windows LibrO_3.4.3-RC1
Comment 2 Laurent Godard 2011-08-18 05:52:41 UTC
Created attachment 50349 [details]
crash stack trace
Comment 3 clio 2011-08-18 07:58:00 UTC
Reproducible on Linux with LibO 3.4.2
Comment 4 Noel Power 2011-08-22 04:53:50 UTC
valgrind log follows ( sorry the line numbers are slightly skewed due to some local debug statements )

unocrsrhelper.cxx:501 should read 
unocrsrhelper.cxx:499 ( if I didn't have the extra debug )

basically the lines should read

    498             if((pTxtNode = (SwTxtNode*)rPam.GetNode( sal_True )) == rPam.GetNode(sal_False) &&
    499                     pTxtNode->GetpSwpHints())
    500             {

and what the valgrind log below is saying is that the cast to SwTxtNode is illegal, in fact the node in question is a SwTableNode.

It would be possible to defensively code the getCrsrPropertyValue(..) method against this situation but it seems that something deeper is wrong here. Clearly the SwXTextCursor believes the SwPam is pointing at text nodes but this isn't the case. It seems the treatment/representation XTextRange for Tables(s) is somewhat weird or strange ( see. SwXTextRange::getStart()/getEnd() wrt treatment of RANGE_IS_TABLE ) 
My gut feeling is the best solution here would be to throw an exception when calling, alternatively I guess SwTextCursor needs to know how to handle itself when it is this special table XTextRange

cursor = doc.text.createTextCursorByRange(table.anchor)

assigning to Cedric who hopefully will know the right thing to do


==30353== Invalid read of size 8
==30353==    at 0x2175507C: SwTxtNode::GetpSwpHints() (ndtxt.hxx:228)
==30353==    by 0x21C0646C: SwUnoCursorHelper::getCrsrPropertyValue(SfxItemPropertySimpleEntry const&, SwPaM&, com::sun::star::uno::Any*, com::sun::star::beans::PropertyState&, SwTxtNode const*) (unocrsrhelper.cxx:501)
==30353==    by 0x21C63397: SwUnoCursorHelper::GetPropertyValue(SwPaM&, SfxItemPropertySet const&, rtl::OUString const&) (unoobj.cxx:1875)
==30353==    by 0x21C64E53: SwXTextCursor::getPropertyValue(rtl::OUString const&) (unoobj.cxx:2233)
==30353==    by 0x2C352E22: ??? (in /data4/OOO_BUILD_GIT/ooo-build/bootstrap/INSTALL_LINK/ure/lib/introspection.uno.so)
==30353==    by 0x2C35530B: ??? (in /data4/OOO_BUILD_GIT/ooo-build/bootstrap/INSTALL_LINK/ure/lib/introspection.uno.so)
==30353==    by 0x2C355373: ??? (in /data4/OOO_BUILD_GIT/ooo-build/bootstrap/INSTALL_LINK/ure/lib/introspection.uno.so)
==30353==    by 0xAAAF029: SbUnoObject::Notify(SfxBroadcaster&, SfxHint const&) (sbunoobj.cxx:2163)
==30353==    by 0x7B144B3: SfxBroadcaster::Broadcast(SfxHint const&) (in /data4/OOO_BUILD_GIT/ooo-build/bootstrap/solver/340/unxlngx6.pro/lib/libsvllx.so)
==30353==    by 0xAB7F2D6: SbxVariable::Broadcast(unsigned long) (sbxvar.cxx:185)
==30353==    by 0xAB68F14: SbxValue::Get(SbxValues&) const (sbxvalue.cxx:389)
==30353==    by 0x2CCB3312: WatchTreeListBox::ImplGetSBXForEntry(SvLBoxEntry*, bool&) (in /data4/OOO_BUILD_GIT/ooo-build/bootstrap/clone/components/basctl/unxlngx6.pro/lib/libbasctllx.so)
==30353==  Address 0xe238410 is 0 bytes after a block of size 112 alloc'd
==30353==    at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==30353==    by 0x400F9A: ??? (in /data4/OOO_BUILD_GIT/ooo-build/bootstrap/INSTALL_LINK/program/soffice.bin)
==30353==    by 0x401026: operator new(unsigned long) (in /data4/OOO_BUILD_GIT/ooo-build/bootstrap/INSTALL_LINK/program/soffice.bin)
==30353==    by 0x21886DE3: SwStartNode::operator new(unsigned long) (in /data4/OOO_BUILD_GIT/ooo-build/bootstrap/solver/340/unxlngx6.pro/lib/libswlx.so)
==30353==    by 0x218922CB: SwNodes::InsertTable(SwNodeIndex const&, unsigned short, SwTxtFmtColl*, unsigned short, unsigned short, SwTxtFmtColl*, SwAttrSet const*) (ndtbl.cxx:585)
==30353==    by 0x218913CB: SwDoc::InsertTable(SwInsertTableOptions const&, SwPosition const&, unsigned short, unsigned short, short, SwTableAutoFmt const*, SvUShorts const*, unsigned char, unsigned char) (ndtbl.cxx:400)
==30353==    by 0x21CDB234: SwXTextTable::attachToRange(com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) (unotbl.cxx:2316)
==30353==    by 0x21CDB5F3: SwXTextTable::attach(com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) (unotbl.cxx:2359)
                                                                                                                                      37,53
Comment 5 Noel Power 2011-08-22 04:56:51 UTC
Created attachment 50446 [details]
maybe patch

the patch raises an exception when calling SwXBodyText::createTextCursorByRange
it is a possible fix for this bug
Comment 6 Cédric Bosdonnat 2011-12-19 07:25:20 UTC
(In reply to comment #5)
> Created attachment 50446 [details] [review]
> maybe patch
> 
> the patch raises an exception when calling SwXBodyText::createTextCursorByRange
> it is a possible fix for this bug

Just pushed it to master... though I'm still wondering if we could have side effects. The comment on XTextContent::getAnchor() made me think that your patch was the best thing to do.
Comment 7 Noel Power 2011-12-19 08:07:06 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Created attachment 50446 [details] [review] [review]
> > maybe patch
> > 
> > the patch raises an exception when calling SwXBodyText::createTextCursorByRange
> > it is a possible fix for this bug
> 
> Just pushed it to master... though I'm still wondering if we could have side
> effects. The comment on XTextContent::getAnchor() made me think that your patch
> was the best thing to do.

hehe well if you don't know then I certainly don't but ( if I understood things right ) it shouldn't make things worse