Summary: | Impress crashes when converting image to 3D rotation object, sometimes after moving the image around thereafter | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Thomas Hackert <thackert> |
Component: | Impress | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | serval2412, telesto, xiscofauli |
Priority: | medium | ||
Version: | 6.0.3.2 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
See Also: | https://crashreport.libreoffice.org/stats/signature/Fraction::GetDenominator()%20const | ||
Whiteboard: | |||
Crash report or crash signature: | ["Fraction::GetDenominator() const"] | Regression By: | |
Bug Depends on: | |||
Bug Blocks: | 104238, 108741 | ||
Attachments: |
"soffice --backtrace" output
Callgrind logs (hopefully the right ones) ... |
Description
Thomas Hackert
2018-05-06 15:18:42 UTC
On pc Debian x86-64 with master sources updated yesterday, I could reproduce this. Badfully, I can't retrieve a bt since I can't reproduce this when using gdb (either with make debugrun or by attaching gdb to the process). However, I had these on console: warn:vcl.gdi:7764:7764:vcl/source/graphic/Manager.cxx:129: Calculated size mismatch. Variable size is '2483788' but calculated size is '1697356' warn:vcl.gdi:7678:7678:vcl/source/outdev/map.cxx:1778: Invalid source map unit soffice.bin: /home/julien/lo/libreoffice/include/o3tl/enumarray.hxx:60: const V& o3tl::enumarray<E, V>::operator[](E) const [with E = MapUnit; V = long int]: Assertion `index>=static_cast<E>(0) && index<=E::LAST' failed. warn:vcl:7678:7678:vcl/source/window/dialog.cxx:864: Dialog::StartExecuteModal() - Parent not visible I can reproduce it in Version: 6.1.0.0.alpha1+ Build ID: 1e2afc9bd3062cfba6b65b45c17a08f298014239 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group I used this imagge ( http://www.misucell.com/data/out/11/IMG_472485.jpg ) to reproduce it.. I can also reproduce it in Version: 6.0.3.2 Build ID: 1:6.0.3~rc2-0ubuntu0.16.04.1~lo2 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group but not in Versión: 6.0.3.2 Id. de compilación: 8f48d515416608e3a835360314dac7e47fd0b821 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group Created attachment 142078 [details]
"soffice --backtrace" output
Hello @ll,
thanks for confirming the bug and sorry for the delay ... :( Have not found the time before to create a backtrace ... :(
Sorry again
Thomas.
Created attachment 142079 [details]
Callgrind logs (hopefully the right ones) ...
Hello @ll,
as I was not able to produce a strace output the crash, I installed valgrind and tried a couple of times to reproduce it with that ... ;) Though it was slowing down my system with "soffice --valgrind" I could not reproduce the crash either but with "algrind --tool=callgrind --simulate-cache=yes --dump-instr=yes LO/instdir/daily/master/opt/libreofficedev6.1/program/soffice --splash-pipe=0" I could somehow reproduce it ...
Sorry for the inconvenience
Thomas.
On pc Debian x86-64 with master sources updated today, I don't reproduce this. Xisco: do you reproduce this with a more recent daily build? Any update with a recent LO version? Indeed, I don't reproduce this with LO Debian package 6.1.5.2. (In reply to Xisco Faulí from comment #2) > I can reproduce it in > > Version: 6.1.0.0.alpha1+ > Build ID: 1e2afc9bd3062cfba6b65b45c17a08f298014239 > CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; > Locale: ca-ES (ca_ES.UTF-8); Calc: group > > I used this imagge ( http://www.misucell.com/data/out/11/IMG_472485.jpg ) to > reproduce it.. Not reproduced in Version: 6.4.0.0.alpha0+ Build ID: 9fbedb7929936a45967ae49bc15b985f95e2ebd3 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded OTOH, no more crash signatures from 6.2.X versions in https://crashreport.libreoffice.org/stats/signature/Fraction::GetDenominator()%20const Closing as RESOLVED WORKSFORME |