If only I could *always* read well ... and I didn't second guess myself so easily ...
The stack trace from 47466 - Crash occurring in Windows 64bit versions... msvcr90!_invalid_parameter_noinfo+0xc sclo!std::_Tree<std::_Tset_traits<short,std::less<short>,std::allocator<short>,0> >::const_iterator::operator*+0x35 [c:\program files\microsoft visual studio 9.0\vc\include\xtree @ 264] sclo!std::_Tree<std::_Tset_traits<short,std::less<short>,std::allocator<short>,0> >::iterator::operator*+0xf [c:\program files\microsoft visual studio 9.0\vc\include\xtree @ 466] sclo!ScDocFunc::AutoFormat+0x520 [d:\losrc\3553\sc\source\ui\docshell\docfunc.cxx @ 3739] sclo!ScViewFunc::AutoFormat+0x70 [d:\losrc\3553\sc\source\ui\view\viewfun2.cxx @ 1575] Is almost identical to yours. You HAVE reproduced fdo#47466. The iterator functions appear to paper over the access at itr.end() everywhere except 1) Windows 64bit where it crashes and 2) your cppcheck which has replaced the standard iterator with a safe iterator, if I am not mistaken. But really the unasked for width adjustments people see could be the result of an uncaught exception shortcutting all the rest of the width/height fix, etc so format does not get restored to fixed width and height during the AutoFormat. Bubbling exception from this could also help explain the report of related undo failures after the errant width/height change as in fdo# 34552 EDITING: Calc loses row height value when modifying a cell https://bugs.freedesktop.org/show_bug.cgi?id=34552 -- if it skips out from the point of the missing braces then it will fail to record the undo info for the width height change and that could cause the behavior there And maybe even other bugs if calls to this AutoFormat function are involved there ... Like https://bugs.freedesktop.org/show_bug.cgi?id=57176 Undo of delete of Conditional Formatting works for one cell but fails for multi-cell (cf. if (bSize) ...) On final note, I don't think that bool ScDocFunc::AutoFormat( const ScRange& rRange, ... will return bSuccess = true under any circumstances. Just sayin' .... ;-) I will seek more bugs and test them before and after the brace insert in the next few days ... Again... looks like a real good catch here. Gratz and thank you for the puzzle. Happy New Year !!! LeMoyne -- View this message in context: http://nabble.documentfoundation.org/Wrong-indentation-which-leads-to-segfault-in-sc-source-ui-docshell-docfunc-cxx-tp4026726p4026757.html Sent from the Dev mailing list archive at Nabble.com. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice