Re: Crash with gnome#627420-1.ods in string related function

We could throw a StringAllocationFailed exception, and catch it near the
bottom if the import process, and use that to indicate that the document is
corrupt.

On Thursday, 3 January 2013, Lubos Lunak wrote:

> 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 <javascript:;>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org <javascript:;>
> http://lists.freedesktop.org/mailman/listinfo/libreoffice