Bugzilla Bug 773

Attempting to open a document that contains no <p></p> pair causes a segfault.
If either is present, the parser recognizes it as a bogus document.

(gdb) bt
#0  0x8111617 in fl_BlockLayout::getPosition (this=0x0, bActualBlockPos=0
'\000') at fl_BlockLayout.cpp:842
#1  0x8111704 in fl_BlockLayout::findPointCoords (this=0x0, iPos=2, bEOL=0
'\000', x=@0xbffff800, y=@0xbffff7fc, height=@0xbffff7f8) at fl_BlockLayout.cpp:877
#2  0x810c661 in FV_View::_findPositionCoords (this=0x8304e90, pos=2, bEOL=0
'\000', x=@0x8304ed8, y=@0x8304edc, height=@0x8304ee0, ppBlock=0x0, ppRun=0x0)
at fv_View.cpp:3460
#3  0x810c738 in FV_View::_fixInsertionPointCoords (this=0x8304e90) at
fv_View.cpp:3498
#4  0x810729d in FV_View::moveInsPtTo (this=0x8304e90, dp=FV_DOCPOS_BOD) at
fv_View.cpp:918
#5  0x8105716 in FV_View::FV_View (this=0x8304e90, pApp=0x82ab320,
pParentData=0x829ac30, pLayout=0x8304760) at fv_View.cpp:114
#6  0x80b68fa in AP_UnixFrame::_showDocument (this=0x829ac30, iZoom=100) at
ap_UnixFrame.cpp:107
#7  0x80b7cb2 in AP_UnixFrame::loadDocument (this=0x829ac30,
    szFilename=0xbffffc45 "break.abw", ieft=0) at ap_UnixFrame.cpp:477
#8  0x80a1074 in AP_UnixApp::parseCommandLine (this=0x82ab320) at ap_UnixApp.cpp:914
#9  0x80a0c44 in AP_UnixApp::main (szAppName=0x81bc448 "AbiWord Personal", argc=2,
    argv=0xbffffaf4) at ap_UnixApp.cpp:808
#10 0x80911eb in main (argc=2, argv=0xbffffaf4) at UnixMain.cpp:24

If you attempt to open a document that has neither a <section> nor a <p>, the
the program also segfaults.  However, the backtrace is different.

(gdb) bt
#0  pf_Frag_Strux::getStruxType (this=0x0) at pf_Frag_Strux.cpp:44
#1  0x812fa11 in pt_PieceTable::_getStruxOfTypeFromPosition (this=0x8316510,
dpos=2,
    pts=PTX_Block, ppfs=0xbfffecc4) at pt_PieceTable.cpp:598
#2  0x812f8bb in pt_PieceTable::getStruxOfTypeFromPosition (this=0x8316510,
listenerId=0,
    docPos=2, pts=PTX_Block, psfh=0xbfffed40) at pt_PieceTable.cpp:546
#3  0x812bf6e in PD_Document::getStruxOfTypeFromPosition (this=0x8312650,
listenerId=0,
    docPos=2, pts=PTX_Block, psfh=0xbfffed40) at pd_Document.cpp:564
#4  0x81182b3 in FL_DocLayout::findBlockAtPosition (this=0x831b008, pos=2)
    at fl_DocLayout.cpp:356
#5  0x8107476 in FV_View::_findBlockAtPosition (this=0x82c4bd0, pos=2) at
fv_View.cpp:960
#6  0x810c615 in FV_View::_findPositionCoords (this=0x82c4bd0, pos=2, bEOL=0
'\000',
    x=@0x82c4c18, y=@0x82c4c1c, height=@0x82c4c20, ppBlock=0x0, ppRun=0x0)
    at fv_View.cpp:3458
#7  0x810c738 in FV_View::_fixInsertionPointCoords (this=0x82c4bd0) at
fv_View.cpp:3498
#8  0x810729d in FV_View::moveInsPtTo (this=0x82c4bd0, dp=FV_DOCPOS_BOD) at
fv_View.cpp:918
#9  0x8105716 in FV_View::FV_View (this=0x82c4bd0, pApp=0x82ab320,
pParentData=0x829ac30,
    pLayout=0x831b008) at fv_View.cpp:114
#10 0x80b68fa in AP_UnixFrame::_showDocument (this=0x829ac30, iZoom=100)
    at ap_UnixFrame.cpp:107
#11 0x80b7cb2 in AP_UnixFrame::loadDocument (this=0x829ac30,
    szFilename=0x82c2380 "/home/sam/break.abw", ieft=0) at ap_UnixFrame.cpp:477
#12 0x80c1af0 in _fileOpen (pFrame=0x829ac30, pNewFile=0x82c2380
"/home/sam/break.abw",
    ieft=IEFT_Unknown) at ap_EditMethods.cpp:1315
#13 0x80c1be4 in ap_EditMethods::fileOpen (pAV_View=0x83050c0) at
ap_EditMethods.cpp:1343
#14 0x816f76c in EV_Menu::invokeMenuMethod (this=0x82b4f10, pView=0x83050c0,
pEM=0x824b1d0,
    pData=0x0, dataLength=0) at ev_Menu.cpp:93
#15 0x816c113 in EV_UnixMenu::menuEvent (this=0x82b4f10, id=3) at
ev_UnixMenu.cpp:276
#16 0x81bb8c6 in _wd::s_onActivate (callback_data=0x82c31c8) at ev_UnixMenu.cpp:66
#17 0x400f0fa7 in gtk_marshal_NONE__NONE () from /usr/lib/libgtk-1.2.so.0
#18 0x401221a6 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
Cannot access memory at address 0x47.

I don't find it particularily surprising that we segfault on these document
problems, but it seems strange that the traces should be different.  If I get
some time, I'll look into this.

More info on this -
In the first case, when there is <section> but not <p></p>, you get two asserts
before the segfault -
**** (1) Assert ****
**** (1) (0) at fl_DocLayout.cpp:372 ****
**** (1) Continue ? (y/n) [y] : n

**** (2) Assert ****
**** (2) pBlock at fv_View.cpp:3529 ****
**** (2) Continue ? (y/n) [y] : y

Isn't this the intended behavior? I mean, every document should have at least
one empty paragraph...

Sam, do you have a sample document ?

Currently this is not a bug but a feature: the piecetable stuff AND the
formatter expect to have at least one PTX_Block in a PTX_Section. If there is
none, it crash. I encountered the problem when implementing header/footer stuff.

As a fix, we should make the importer add a PTX_Block if there is none in the
file. This allow working around corrupt file of some sort.

BTW if AbiWord write such a file, it is a real bug.

Created an attachment (id=67) [edit]
test case

dom> Isn't this the intended behavior? I mean, every document should have at 
dom> least one empty paragraph...

well good lord, it shouldn't cause a crash!

I just fixed this. Will check in when i can connect to abiword cvs again

works for me

closing verified bugs whose target is no longer