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