On Thursday 03 of January 2013, Markus Mohrhard wrote:
Hey,
while going through the list of calc documents crashing during import
I came across gnome#627420-1.ods which creates an insanely large
OUStringBuffer that ultimately leads to a crash. Since I believe we
have quite a few places contain such problems. I wanted to ask if we
should not try to find a solution in the string classes instead of
having crashs with such documents from time to time.
The question is, what kind of solution do you expect? Presumably the crash
was because the allocation failed and the assert was a no-op because of
non-debug build, leading to NULL pointer dereference. So probably the only
thing we can do is have the assert always active, changing the crash to a
different kind of crash, but that seems to be about it.
The crash happens
in:
void SAL_CALL IMPL_RTL_STRINGNAME( new_WithLength )(
IMPL_RTL_STRINGDATA** ppThis, sal_Int32 nLen ) SAL_THROW_EXTERN_C()
with
*ppThis = IMPL_RTL_STRINGNAME( ImplAlloc )( nLen );
OSL_ASSERT(*ppThis != NULL);
(*ppThis)->length = 0;
in the assignment of length to zero.
--
Lubos Lunak
l.lunak@suse.cz
Context
- Re: Crash with gnome#627420-1.ods in string related function · Lubos Lunak
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.