Invalid Collada file crash blender #43094

New Issue

Jorge Ortega · 2015-01-01T19:08:04+01:00

Jorge Ortega commented

2015-01-01 19:08:04 +01:00

System Information
Windows 8.1 x64, nvidia quadro 600 and nvidia GTX-660TI

Blender Version
Blender 2.73 testbuild 1 - hash d7e4944

Short description of error
Open Collada file makes Blender close, no error message, no crash, nothing.

Exact steps for others to reproduce the error
Extract the attached zip file. is a DAE file produced with the FBX converter 2013.3. Try to import the file into Blender -> Blender closes with no error message or whatever.

test3.zip

**System Information** Windows 8.1 x64, nvidia quadro 600 and nvidia GTX-660TI **Blender Version** Blender 2.73 testbuild 1 - hash d7e4944 **Short description of error** Open Collada file makes Blender close, no error message, no crash, nothing. **Exact steps for others to reproduce the error** Extract the attached zip file. is a DAE file produced with the FBX converter 2013.3. Try to import the file into Blender -> Blender closes with no error message or whatever. [test3.zip](https://archive.blender.org/developer/F134590/test3.zip)

Jorge Ortega commented

2015-01-01 19:08:04 +01:00

Changed status to: 'Open'

Jorge Ortega commented

2015-01-01 19:08:04 +01:00

Added subscriber: @jortega

Aaron Carlisle self-assigned this 2015-01-01 21:51:51 +01:00

Aaron Carlisle removed their assignment 2015-01-01 21:52:19 +01:00

Gaia Clary was assigned by Bastien Montagne

2015-01-01 22:01:12 +01:00

Bastien Montagne commented

2015-01-01 22:01:12 +01:00

Added subscribers: @Blendify, @mont29

Bastien Montagne commented

2015-01-01 22:01:12 +01:00

@Blendify: Please do not edit reprot that way when you are not sure… Collada is BF-blender, not addon. And you do not need to claim the task to edit those properties, only adds noise.

@jortega: One thing for sure, this collada file I would consider invalid/corrupted (it only contains two vcol values, instead of one per vertex…).

@Gaia: assigning to you in case you have an idea to avoid crash here? tried investigating a bit, but index_list.getIndicesCount() returns the number of vertices, not '2' as I would expect here… Maybe bug is actually in collada framework itself?

@Blendify: Please do not edit reprot that way when you are not sure… Collada is BF-blender, not addon. And you do not need to claim the task to edit those properties, only adds noise. @jortega: One thing for sure, this collada file I would consider invalid/corrupted (it only contains two vcol values, instead of one per vertex…). @Gaia: assigning to you in case you have an idea to avoid crash here? tried investigating a bit, but `index_list.getIndicesCount()` returns the number of vertices, not '2' as I would expect here… Maybe bug is actually in collada framework itself?

Bastien Montagne changed title from ~~Collada file crash blender~~ to Invalid Collada file crash blender

2015-01-01 22:01:43 +01:00

Aaron Carlisle commented

2015-01-01 22:06:35 +01:00

I tried importing the file two time the first time it crashed the 2nd nothing was new in the view port but many new files in the out-liner

Aaron Carlisle commented

2015-01-01 22:12:10 +01:00

This could be a memory bug also since the file contains about 700 objects

Bastien Montagne commented

2015-01-01 22:24:45 +01:00

As said, this is not a memory bug, and not even a bug at all, this is an invalid collada file that only has two vcol values (RGBA tuples) when it should have one per vertex…

Other report with matching FBX file suffered the same issue, btw, but thanks to py we avoid crash and just get an exception. So just keeping open in case Gaia has a simple idea to avoid crash here too.

As said, this is not a memory bug, and not even a bug at all, this is an invalid collada file that only has two vcol values (RGBA tuples) when it should have one per vertex… Other report with matching FBX file suffered the same issue, btw, but thanks to py we avoid crash and just get an exception. So just keeping open in case Gaia has a simple idea to avoid crash here too.

Julian Eisel commented

2015-02-03 14:13:52 +01:00

Added subscribers: @GaiaClary, @JulianEisel

Julian Eisel commented

2015-02-03 14:13:52 +01:00

@GaiaClary, found the time to look into it?

Julian Eisel commented

2015-02-26 18:43:43 +01:00

Changed status from 'Open' to: 'Archived'

Julian Eisel closed this issue

2015-02-26 18:43:43 +01:00

Julian Eisel commented

2015-02-26 18:43:43 +01:00

Closing this for now, for the reasons given by @mont29. If @GaiaClary comes up with an idea on how we could handle this from Blender's side, we can still reopen (although it might be considered as a todo then)

Gaia Clary commented

2015-02-27 19:48:40 +01:00

This comment was removed by @GaiaClary

*This comment was removed by @GaiaClary*

Gaia Clary commented

2015-02-27 20:30:44 +01:00

So the test file contains:

<source id="_ncl1_65-POSITION">...  <!-- 144 entries -->
<source id="_ncl1_65-Normal0">...     <!-- 144 entries -->
<source id="_ncl1_65-VERTEX_COLOR0">...  <!-- 9 entries -->

<vertices id="_ncl1_65-VERTEX">
  <input semantic="POSITION" source="#_ncl1_65-POSITION"/>
  <input semantic="NORMAL" source="#_ncl1_65-Normal0"/>
  <input semantic="COLOR" source="#_ncl1_65-VERTEX_COLOR0"/>
</vertices>

<triangles count="48">
  <input semantic="VERTEX" offset="0" source="#_ncl1_65-VERTEX"/>
  <p> 0 1 2 3 4 5 6 7 ... 139 140 141 142 143</p>
</triangles>

This means the

element only contains one set of indices
for the set "#_ncl1_65-VERTEX". But the source
"#_ncl1_65-VERTEX" contains definitions for:

POSITION, NORMAL and COLOR.

The problem is which index should be used to access the data (source)
of the 3 lists?

Blender (actually OpenCollada) expects that the 3 sources for
POSITION, NORMAL and COLOR contain the same amount
of entries. So each entry in the

list is an index
that can be used for all 3 sources equally.

But there are only 9 entries in the color source.
Hence Blender creates an exception when trying to read
the color array (because we use indices from 0 up to 143 to access it)

when i compare that to the structure of a Dae file that was
created by blender (for the default cube with vertex colors)
then i see some significant differences:

<source id="Cube-mesh-positions"> <!-- 8 entries -->
<source id="Cube-mesh-normals"> <!-- 12 entries -->
<source id="Cube-mesh-colors-Col" name="Col"> <!-- 36 entries -->

<vertices id="Cube-mesh-vertices">
  <input semantic="POSITION" source="#Cube-mesh-positions"/>
</vertices>
<polylist material="Material-material" count="12">
  <input semantic="VERTEX" source="#Cube-mesh-vertices" offset="0"/>
  <input semantic="NORMAL" source="#Cube-mesh-normals" offset="1"/>
  <input semantic="COLOR" source="#Cube-mesh-colors-Col" offset="2" set="0"/>
  <p> ...</p>
  <vcount>...</vcount>  <!-- loopcount per polygon -->
</polylist>

The main difference is that Blender specifies the input sources within the polylist.
this means the

list contains separate indices for VERTEX, NORMAL and COLOR
and now the sources can have different size but we still get correct results because the
index sets are now specific for each source.

So after analyzing all of this i come to the conclusion that the test file is corrupted.
But then it is easy to fix blender. I just need to check if a used index gets out of bounds.

Could someone please approve or correct my assumptions?
thanks.

So the test file contains: ``` <source id="_ncl1_65-POSITION">...  <source id="_ncl1_65-Normal0">...  <source id="_ncl1_65-VERTEX_COLOR0">...  ``` ``` <vertices id="_ncl1_65-VERTEX"> <input semantic="POSITION" source="#_ncl1_65-POSITION"/> <input semantic="NORMAL" source="#_ncl1_65-Normal0"/> <input semantic="COLOR" source="#_ncl1_65-VERTEX_COLOR0"/> </vertices> ``` ``` <triangles count="48"> <input semantic="VERTEX" offset="0" source="#_ncl1_65-VERTEX"/> <p> 0 1 2 3 4 5 6 7 ... 139 140 141 142 143</p> </triangles> ``` This means the <p> element only contains one set of indices for the set "#_ncl1_65-VERTEX". But the source "#_ncl1_65-VERTEX" contains definitions for: ``` POSITION, NORMAL and COLOR. ``` The problem is which index should be used to access the data (source) of the 3 lists? Blender (actually OpenCollada) expects that the 3 sources for POSITION, NORMAL and COLOR contain the same amount of entries. So each entry in the <p> list is an index that can be used for all 3 sources equally. But there are only 9 entries in the color source. Hence Blender creates an exception when trying to read the color array (because we use indices from 0 up to 143 to access it) ---- when i compare that to the structure of a Dae file that was created by blender (for the default cube with vertex colors) then i see some significant differences: ``` <source id="Cube-mesh-positions">  <source id="Cube-mesh-normals">  <source id="Cube-mesh-colors-Col" name="Col">  ``` ``` <vertices id="Cube-mesh-vertices"> <input semantic="POSITION" source="#Cube-mesh-positions"/> </vertices> <polylist material="Material-material" count="12"> <input semantic="VERTEX" source="#Cube-mesh-vertices" offset="0"/> <input semantic="NORMAL" source="#Cube-mesh-normals" offset="1"/> <input semantic="COLOR" source="#Cube-mesh-colors-Col" offset="2" set="0"/> <p> ...</p> <vcount>...</vcount>  </polylist> ``` The main difference is that Blender specifies the input sources within the polylist. this means the <p> list contains separate indices for VERTEX, NORMAL and COLOR and now the sources can have different size but we still get correct results because the index sets are now specific for each source. So after analyzing all of this i come to the conclusion that the test file is corrupted. But then it is easy to fix blender. I just need to check if a used index gets out of bounds. Could someone please approve or correct my assumptions? thanks.

Gaia Clary commented

2015-02-27 20:31:05 +01:00

Changed status from 'Archived' to: 'Open'

Gaia Clary reopened this issue

2015-02-27 20:31:05 +01:00

blender-admin commented

2015-03-03 23:42:32 +01:00

This issue was referenced by 7f25da6509

This issue was referenced by 7f25da650943aa24d7f851552c1a9741b0ba6891

Gaia Clary commented

2015-03-03 23:43:04 +01:00

Changed status from 'Open' to: 'Resolved'