On Wed, 2020-04-08 at 04:30 +0000, crashtest wrote: > New crashtest update available at > https://dev-builds.libreoffice.org/crashtest/27d04f6dbf38aa28fb7215590d578c4567db57 There's a bunch of the same assert listed there: vcl/source/outdev/map.cxx:366: long int ImplLogicToPixel(long int, long int, long int, long int, long int): Assertion `nMapNum == 0 || std::abs(n) < std::numeric_limits<long>::max() / nMapNum / nDPI' failed. using ./soffice --headless --convert-to pdf on e.g. the svg attachment https://bugzilla.mozilla.org/attachment.cgi?id=9058902 (of mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1545040) reproduces this The assert seems to have become noticeable since commit 62ac8333999c661432adb0a18245a399daa89dcb (HEAD) Date: Fri Feb 14 16:47:14 2020 +0100 tdf#130655 callback interface for 3D and secure dash But that looks blameless in the sense that it probably just timed out before that change. The original svg contains massive numbers in the input source path. Anyone got any thoughts about what we should do with cases like this ? _______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice