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.
Context
- Re: Wrong indentation which leads to segfault in sc/source/ui/docshell/docfunc.cxx · John LeMoyne Castle
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.