Problem description: Inserting .dae or .kmz objects makes LO crash on up-to-date Linux Mint Debian Edition. Steps to reproduce: 1. Launch LibreOffice 4.3.1.2 2. Create new Impress presentation 3. Insert/Object/3d Model 4. Select any .dae or .kmz file, for instance, any one downloaded from 3dwarehouse.sketchup.com such as https://3dwarehouse.sketchup.com/warehouse/getpubliccontent?contentId=3131c2e7-6b96-4735-b296-fd73fe4b2dfe&fn=Arduino_Display_module_of_noise_level.kmz. Current behavior: When run from console I see the following message after crash: user@machine ~ $ libreoffice4.3 --impress /tmp/h4UDpl(1): expected object or array As my machine is an Optimus dual GPU notebook, I try using optirun command to enable NVIDIA GPU instead of regular display, same effect only different temp file. No other message appears. Expected behavior: I should see 3d model inserted. Operating System: Debian Version: 4.3.1.2 release
I'd think it's interesting to know that documents published in: http://zolnaitamas.blogspot.com.ar/2014/08/3d-models-in-impress-libreoffice-43.html load OK and model representation/animation perform flawlessly. It's the insertion at edition what fails.
Hi Eduardo, Thanks for the link. Can you see in Bug 82476 - Crash in presentation with 3D animated model. Under Windws 7 Home Prmeium, insertion works. regards, Jacques
Confirmed with v4.3.1.2 under mint 17 x64. Confirmed with v4.3.1.2 under ubuntu 14.04 x64. Unconfirmed with v4.3.1.2 under windows 7 x64. Looks linux only, perhaps someone with a mac can test it too. Set to NEW.
(In reply to comment #2) > Hi Eduardo, > > Thanks for the link. > Can you see in Bug 82476 - Crash in presentation with 3D animated model. > Under Windws 7 Home Prmeium, insertion works. > The feature will only be available in 4.4 for Mac. We still need to fix a few problems around the Mac OpenGL support. A back trace would help here.
Hi Eduardo, Thanks for the bug report. This error message comes from the *.json (main file of gltf format) parser and it means that the input is empty. So it must be some problem with the dae -> gltf conversion's generated files. It would be useful if you can check the name and count of those temporary folders and files which are generated when you insert a 3D model. You also can check whether this /tmp/h4UDpl(1) file exist / is empty or not. In this case back trace won't help since I can say where it crashes :): in libgltf external library: under src/libgltf.cpp inside gltf_renderer_init() method. This crash is already fixed in 4.3.2, which means Impress won't crash, just display a question mark in such cases as yours. Apart from that conversion still broken on your machine.
(In reply to comment #2) > Hi Eduardo, > > Thanks for the link. > Can you see in Bug 82476 - Crash in presentation with 3D animated model. > Under Windws 7 Home Prmeium, insertion works. > > regards, > > Jacques Bug 82476 is not really related to 3D models. As it comes out from the conversion there it is something with the media toolbar handling. (media toolbar is used by movies and 3D models)
Hi Eduardo, Other helpful thing would be if you can test whether inserting a 3D model in glTF format (so not dae or kmz) work or not. I uploaded a compressed glTF model for testing if you have time for that: people.collabora.com/~ztamas/duck.tar.gz Thanks!
Hi The litle ducky shows OK!
(In reply to comment #5) > Hi Eduardo, > > Thanks for the bug report. > > This error message comes from the *.json (main file of gltf format) parser > and it means that the input is empty. So it must be some problem with the > dae -> gltf conversion's generated files. > > It would be useful if you can check the name and count of those temporary > folders and files which are generated when you insert a 3D model. You also > can check whether this /tmp/h4UDpl(1) file exist / is empty or not. > > In this case back trace won't help since I can say where it crashes :): > in libgltf external library: under src/libgltf.cpp inside > gltf_renderer_init() method. > > This crash is already fixed in 4.3.2, which means Impress won't crash, just > display a question mark in such cases as yours. Apart from that conversion > still broken on your machine. The file does exist: user@machine ~ $ libreoffice4.3 /tmp/wlrvmU(1): expected object or array user@machine ~ $ ls -l /tmp/wlrvmU -rw------- 1 user user 193273 Sep 26 09:55 /tmp/wlrvmU user@machine ~ $ file /tmp/wlrvmU /tmp/wlrvmU: Zip archive data, at least v2.0 to extract user@machine ~ $ unzip /tmp/wlrvmU Archive: /tmp/wlrvmU inflating: doc.kml inflating: models/untitled/texture.JPG inflating: models/untitled/texture_0.png inflating: models/untitled.dae I can send more about these files if it helps.
(In reply to comment #5) > It would be useful if you can check the name and count of those temporary > folders and files which are generated when you insert a 3D model. Would you please point me to where these folders and files should appear.
(In reply to comment #10) > (In reply to comment #5) > > > It would be useful if you can check the name and count of those temporary > > folders and files which are generated when you insert a 3D model. > > Would you please point me to where these folders and files should appear. All the new files under the /tmp/ folder created when you insert a 3D model (next to that one which appears in the terminal output). I used to sort folders / files by creation date and so I see which is created by the last run of Impress. Optimally there is no other application running and creating temp files.
(In reply to comment #9) > (In reply to comment #5) > > Hi Eduardo, > > > > Thanks for the bug report. > > > > This error message comes from the *.json (main file of gltf format) parser > > and it means that the input is empty. So it must be some problem with the > > dae -> gltf conversion's generated files. > > > > It would be useful if you can check the name and count of those temporary > > folders and files which are generated when you insert a 3D model. You also > > can check whether this /tmp/h4UDpl(1) file exist / is empty or not. > > > > In this case back trace won't help since I can say where it crashes :): > > in libgltf external library: under src/libgltf.cpp inside > > gltf_renderer_init() method. > > > > This crash is already fixed in 4.3.2, which means Impress won't crash, just > > display a question mark in such cases as yours. Apart from that conversion > > still broken on your machine. > > The file does exist: > > user@machine ~ $ libreoffice4.3 > /tmp/wlrvmU(1): expected object or array > user@machine ~ $ ls -l /tmp/wlrvmU > -rw------- 1 user user 193273 Sep 26 09:55 /tmp/wlrvmU > user@machine ~ $ file /tmp/wlrvmU > /tmp/wlrvmU: Zip archive data, at least v2.0 to extract > user@machine ~ $ unzip /tmp/wlrvmU > Archive: /tmp/wlrvmU > inflating: doc.kml > inflating: models/untitled/texture.JPG > inflating: models/untitled/texture_0.png > inflating: models/untitled.dae > > I can send more about these files if it helps Not necessary. Here is the problem, this file should not be a zipped file. Hmm. Did you compile LO from source or downloaded a binary?
> > The file does exist: > > > > user@machine ~ $ libreoffice4.3 > > /tmp/wlrvmU(1): expected object or array > > user@machine ~ $ ls -l /tmp/wlrvmU > > -rw------- 1 user user 193273 Sep 26 09:55 /tmp/wlrvmU > > user@machine ~ $ file /tmp/wlrvmU > > /tmp/wlrvmU: Zip archive data, at least v2.0 to extract > > user@machine ~ $ unzip /tmp/wlrvmU > > Archive: /tmp/wlrvmU > > inflating: doc.kml > > inflating: models/untitled/texture.JPG > > inflating: models/untitled/texture_0.png > > inflating: models/untitled.dae > > > > I can send more about these files if it helps Can you also check the type of this file when you insert a *.dae file? ( I expect that this output belongs to a kmz file) Here is an example dae model (find dae file under model subfolder): people.collabora.com/~ztamas/maze.tar.gz The conversion chain is like that kmz -> dae -> glTF, so it is helpful to see how this file looks like in case of dae files too.
Created attachment 106928 [details] File list comparison
(In reply to comment #12) > > I can send more about these files if it helps > > Not necessary. Here is the problem, this file should not be a zipped file. > Hmm. > Did you compile LO from source or downloaded a binary? I downloaded the torrent for LibreOffice_4.3.1_Linux_x86_deb.tar.gz binaries pack, torrented it down, then opened it, then installed the bunch of debs with dpkg -i. I also dpkg -removed previous LO installs but that may have been AFTER installing 4.3.1.
Created attachment 106929 [details] Second capture of file list meld
(In reply to comment #13) > > > The file does exist: > > > > > > user@machine ~ $ libreoffice4.3 > > > /tmp/wlrvmU(1): expected object or array > > > user@machine ~ $ ls -l /tmp/wlrvmU > > > -rw------- 1 user user 193273 Sep 26 09:55 /tmp/wlrvmU > > > user@machine ~ $ file /tmp/wlrvmU > > > /tmp/wlrvmU: Zip archive data, at least v2.0 to extract > > > user@machine ~ $ unzip /tmp/wlrvmU > > > Archive: /tmp/wlrvmU > > > inflating: doc.kml > > > inflating: models/untitled/texture.JPG > > > inflating: models/untitled/texture_0.png > > > inflating: models/untitled.dae > > > > > > I can send more about these files if it helps > > Can you also check the type of this file when you insert a *.dae file? > ( I expect that this output belongs to a kmz file) > Here is an example dae model (find dae file under model subfolder): > people.collabora.com/~ztamas/maze.tar.gz > > The conversion chain is like that kmz -> dae -> glTF, so it is helpful to > see how this file looks like in case of dae files too. My session: oso@osobook /tmp $ ls -l > list01.txt oso@osobook /tmp $ libreoffice4.3 /tmp/h1oLZM(1): expected object or array oso@osobook /tmp $ ls -l > list02.txt oso@osobook /tmp $ meld list01.txt list02.txt // ATTACHING CAPTURE OF MELD oso@osobook /tmp $ mkdir LO2 oso@osobook /tmp $ mv 0S9TSE h1oLZM ludo0gen.tmp/ LO2 oso@osobook /tmp $ cd LO2 oso@osobook /tmp/LO2 $ ll total 1292 -rw------- 1 oso oso 657968 Sep 26 14:27 0S9TSE -rw------- 1 oso oso 657968 Sep 26 14:27 h1oLZM drwx------ 2 oso oso 4096 Sep 26 14:27 ludo0gen.tmp oso@osobook /tmp/LO2 $ mkdir 0S9TSE.dir oso@osobook /tmp/LO2 $ mkdir h1oLZM.dir oso@osobook /tmp/LO2 $ cd 0S9TSE.dir/ oso@osobook /tmp/LO2/0S9TSE.dir $ unzip ../0S9TSE Archive: ../0S9TSE End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of ../0S9TSE or ../0S9TSE.zip, and cannot find ../0S9TSE.ZIP, period. oso@osobook /tmp/LO2/0S9TSE.dir $ cd .. oso@osobook /tmp/LO2 $ ll total 1300 -rw------- 1 oso oso 657968 Sep 26 14:27 0S9TSE drwxr-xr-x 2 oso oso 4096 Sep 26 14:29 0S9TSE.dir -rw------- 1 oso oso 657968 Sep 26 14:27 h1oLZM drwxr-xr-x 2 oso oso 4096 Sep 26 14:29 h1oLZM.dir drwx------ 2 oso oso 4096 Sep 26 14:27 ludo0gen.tmp oso@osobook /tmp/LO2 $ file * 0S9TSE: XML document text 0S9TSE.dir: directory h1oLZM: XML document text h1oLZM.dir: directory ludo0gen.tmp: directory oso@osobook /tmp/LO2 $ head 0S9TSE <?xml version="1.0" encoding="utf-8"?> <COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1"> <asset> <contributor> <authoring_tool>Google 3D Warehouse 1.0</authoring_tool> </contributor> <created>2009-11-20T01:20:43Z</created> <modified>2009-11-20T01:20:43Z</modified> <unit name="meters" meter="1.0"/> <up_axis>Z_UP</up_axis> oso@osobook /tmp/LO2 $ head h1oLZM <?xml version="1.0" encoding="utf-8"?> <COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1"> <asset> <contributor> <authoring_tool>Google 3D Warehouse 1.0</authoring_tool> </contributor> <created>2009-11-20T01:20:43Z</created> <modified>2009-11-20T01:20:43Z</modified> <unit name="meters" meter="1.0"/> <up_axis>Z_UP</up_axis>
Zolnai Tamas committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=93f9451340957dae29a6b3ccec127a99a03ffd31 fdo#84008: make configure fail if no std::shared_ptr available for collada The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi Eduard, Thanks all of the information. This is a packaging problem. I can reproduce the bug with the packages downloaded from libreoffice download site (under opensuse), but can't reproduce with source compiled version. I wrote to the developer mailing list, will get back with the result (whether existing packages will be fixed or only new ones will be created on the right way)
You can see the discussion here: http://lists.freedesktop.org/archives/libreoffice/2014-September/063642.html A patch is waiting for review: https://gerrit.libreoffice.org/#/c/11706/
Patch was pushed: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-3-3&id=c48190a89507ad2a3e6e05c1281b014ad9be0552 and the feature should work in 4.3.3 linux packages.
I tested the 4.3.3.1 linux x86 rpm package and collada\kmz support works.