https://bugs.freedesktop.org/show_bug.cgi?id=47018
--- Comment #13 from Stephan van den Akker <[email protected]> --- I have been investigating the cause of this crash for some time now, and these are my findings so far: The immediate cause of the crash is in file: /cui/source/tabpages/numpages.cxx method: SvxNumOptionsTabPage::InitControls() This method is called every time the user opens the numbering options tab page. In this method the local variable nLvl is used as an index into local variable aNumFmtArr[SVX_MAX_NUM], a vector of pointers. On valid input: SvxNumOptionsTabPage::pActNum->GetLevelCount() = 10 in a for-loop the local variable sal_uInt16 nLvl is set to the 0-based index of the Numbering Level chosen by the user On invalid input (after the botched copying of a bulleted text line, see my OP) SvxNumOptionsTabPage::pActNum->GetLevelCount() = 0 the for-loop is skipped: nLvl = USHRT_MAX (= initialisation value) nLvl is then used as an index into local variable aNumFmtArr[SVX_MAX_NUM], a vector of pointers. On my home system: SVX_MAX_NUM = 10 USHRT_MAX = 65535 USHRT_MAX >> SVX_MAX_NUM, so LibreOffice segfaults because of the out-of-bounds index. Maybe SvxNumOptionsTabPage::InitControls() could be adapted to allow for this kind of invalid input by doing some kind of range check, but that is not what I propose. I want to find the real cause of this invalid input, and that is in the code that does the copying and pasting. More on that in a later post. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
