On 18/05/12 10:31, Noel Power wrote:
On 18/05/12 10:26, Noel Power wrote:
Hi
somewhat of a containing fix ( I think there is other rework needed,
see below ) that avoids the mentioned crasher, please consider
cherry-picking to 3.5
Always ( afaict ) the code expects the index of the entry in the
(maTabs) vector to correspond a tab of the same index. However the
DeleteTab routine patched above will erase the entry for the tab but
if that tab isn't the last tab but instead some random tab in the
middle won't the order of the tabs be screwed ? We could check and
only delete an entry if it is the last entry ( and otherwise make a
null entry for the deleted tab ) but then we definitely would expect
the code should be ready to deal with such a 'hole' (representing a
sheet that no longer exists ) in the vector, that doesn't appear to
be the case. Is this how it should work ? I could rework it like that
if that is the intention, is it ?
and I forgot to mention the commit ( or actually 2 commit ids as it
appears I introduced a wae that was fixed by sb )
http://cgit.freedesktop.org/libreoffice/core/commit/?id=8b1d29bc9b00bc2730738a990023a65ab6e0219b
&
http://cgit.freedesktop.org/libreoffice/core/commit/?id=abb26f51eea0399754cc8f5b7d7a7d648d68f630
I took it that it should work how I outlined above and committed a
further fix which should safeguard against illegal access, please
additionally consider
http://cgit.freedesktop.org/libreoffice/core/commit/?id=8352eb5a1af1eb44550a9d60d31e6c2fb2dc43b9
thanks,
Noel
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
