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: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <a href="javascript:;" onclick="_e(event, 'cvml', 'l.lunak@suse.cz')">l.lunak@suse.cz</a> _______________________________________________ LibreOffice mailing list <a href="javascript:;" onclick="_e(event, 'cvml', 'LibreOffice@lists.freedesktop.org')">LibreOffice@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a> </blockquote>