Bug 84008 - EDITING: Crash when inserting 3D Model
Summary: EDITING: Crash when inserting 3D Model
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.3.1.2 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA target:4.4.0
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-17 16:41 UTC by Eduardo Grosclaude
Modified: 2014-10-20 06:04 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
File list comparison (266.66 KB, image/png)
2014-09-26 17:18 UTC, Eduardo Grosclaude
Details
Second capture of file list meld (269.60 KB, image/png)
2014-09-26 17:33 UTC, Eduardo Grosclaude
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eduardo Grosclaude 2014-09-17 16:41:53 UTC
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
Comment 1 Eduardo Grosclaude 2014-09-18 12:39:04 UTC
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.
Comment 2 Jacques Guilleron 2014-09-18 21:08:38 UTC
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
Comment 3 MM 2014-09-19 11:18:12 UTC
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.
Comment 4 Markus Mohrhard 2014-09-26 11:00:26 UTC
(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.
Comment 5 Tamás Zolnai 2014-09-26 11:49:00 UTC
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.
Comment 6 Tamás Zolnai 2014-09-26 11:56:14 UTC
(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)
Comment 7 Tamás Zolnai 2014-09-26 12:11:32 UTC
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!
Comment 8 Eduardo Grosclaude 2014-09-26 12:52:03 UTC
Hi
The litle ducky shows OK!
Comment 9 Eduardo Grosclaude 2014-09-26 13:02:07 UTC
(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.
Comment 10 Eduardo Grosclaude 2014-09-26 13:16:05 UTC
(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.
Comment 11 Tamás Zolnai 2014-09-26 16:47:44 UTC
(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.
Comment 12 Tamás Zolnai 2014-09-26 16:54:51 UTC
(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?
Comment 13 Tamás Zolnai 2014-09-26 17:13:18 UTC
> > 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.
Comment 14 Eduardo Grosclaude 2014-09-26 17:18:26 UTC
Created attachment 106928 [details]
File list comparison
Comment 15 Eduardo Grosclaude 2014-09-26 17:23:43 UTC
(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.
Comment 16 Eduardo Grosclaude 2014-09-26 17:33:33 UTC
Created attachment 106929 [details]
Second capture of file list meld
Comment 17 Eduardo Grosclaude 2014-09-26 17:34:58 UTC
(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>
Comment 18 Commit Notification 2014-09-27 06:04:35 UTC
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.
Comment 19 Tamás Zolnai 2014-09-27 06:30:45 UTC
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)
Comment 20 Tamás Zolnai 2014-10-01 18:57:00 UTC
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/
Comment 21 Tamás Zolnai 2014-10-09 10:50:26 UTC
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.
Comment 22 Tamás Zolnai 2014-10-20 06:04:08 UTC
I tested the 4.3.3.1 linux x86 rpm package and collada\kmz support works.