Re: Wrong indentation which leads to segfault in sc/source/ui/docshell/docfunc.cxx

2013-01-02 Thread Lubos Lunak
On Tuesday 01 of January 2013, John LeMoyne Castle wrote: Julien, Looks to me like a very nice catch ... ... The next version (2011.07.05) http://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/docfunc.cxx ?r=2b88f6d32f572792597ccbb15276b9db52db7d10 is a commit labelled quot;change

Re: Wrong indentation which leads to segfault in sc/source/ui/docshell/docfunc.cxx

2013-01-01 Thread julien2412
Thank you John for your investigation about all this. In fact, I was leafing through some cppcheck reports. To simplify, I pushed some slight fixes in sc/source/core/tool/autoform.cxx (see http://cgit.freedesktop.org/libreoffice/core/commit/?id=2e1abe1c59b1121ffb5d46afe82ce985cb70c4db). So now

Re: Wrong indentation which leads to segfault in sc/source/ui/docshell/docfunc.cxx

2013-01-01 Thread julien2412
BTW, it's not cppcheck which had safe iterator since it just allow to scan sources. I rather think it's --enable-dbgutil in autogen.lastrun which triggered safe iterator. Julien -- View this message in context:

Wrong indentation which leads to segfault in sc/source/ui/docshell/docfunc.cxx

2012-12-31 Thread julien2412
Hello, 1) Trying to reproduce fdo#47466 with master sources updated this morning, I had this: #0 0x7ff8cd039475 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7ff8cd03c6f0 in *__GI_abort () at abort.c:92 #2 0x7ff8cd8de31d in

Re: Wrong indentation which leads to segfault in sc/source/ui/docshell/docfunc.cxx

2012-12-31 Thread John LeMoyne Castle
Julien, Looks to me like a very nice catch ... Here is the version as of 2011.06.15 showing braces on the for loops in both then and else blocks... from open grok -- http://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/docfunc.cxx?r=1b363f632110e80ead67ff376e92e4487556ca55

Re: Wrong indentation which leads to segfault in sc/source/ui/docshell/docfunc.cxx

2012-12-31 Thread John LeMoyne Castle
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::_Treestd::_Tset_traitslt;short,std::lesslt;short,std::allocatorshort,0