Access Violation when reading domSource->getFloat_array()

Hello,

I’m implementing a converter from Collada to my own format using the integration implementations.

As you have read in the topic, I have an access violation when reading domSource->getFloat_array()

Here is the code:

bool  
intGeometry::exportVertexSource(Mesh *mesh,  
								domInputLocalOffset *inputElement,  
								domPolygons *polygonsElement, 
								int totalOffset) 
{ 
	domURIFragmentType uri = inputElement->getSource(); 
	//Is uri already resolved? 
	if(uri.getState() != daeURI::uri_success)  
	{ 
		//try to resolve it and check again 
		uri.resolveElement(); 
		if(uri.getState() != daeURI::uri_success) { 
			return false; 
		} 
	} 
 
	domElement *element = uri.getElement(); 
	if(!element) { 
		return false; 
	} 
 
	//check source existence 
	domSource *sourceElement = (domSource*)element; 
	if(!sourceElement) { 
		return false; 
	} 
	if(!sourceElement->getFloat_array()) { 
		return false; 
	} /*...*/

The last statement result in an access violation. VC 2003 points me to:

inline void ref() const {_refCount++;}

in daeelement.h, line 100

Is there something wrong in my way of accessing the source-data? I could access the vertices in domMesh, but for proper indexing, etc. I think this is the preferred way?! Furthermore, I understood that this is the only way of accessing normal and texcoord data (polygons->input->source)

Regards,
Sebastian Jancke

Hi,

I’m not really sure about this one. It could be helpful if it is possible to send me your source. I guess just the integration class that this code is in would work. I wouldn’t be able to look into it till tuesday or so but I may be able to find out whats going on.

Until then it sounds like one of two things is going on.

  1. an implicit conversion/copy is happening somewhere and the ref is getting thrown away causing the refcount to decrement to 0 and delete the element. All your pointers will still be !NULL but access violations when doing anything. This would be in the code leading up to the place where it actually crashes.
  2. That is happening right on the line that is crashing.

Well I guess thats only one thing. Be careful about what gets returned from the calls you make. Sometimes things may copy and cause problems like this.

Sorry I can’t be of more help but without actively debugging the code I don’t know.

-Andy

Hey,
I figured out whats going on.
You are casting an element to a wrong type.
The input with a sementic “VERTEX” points to the vertices element which in turn has inputs that point to the sources.
So you are treating a domVertices as a domSource and its getting all messed up.

To avoid problems like this in the future you may want to implement a safe cast function like richforster posted here on sourceforge, or a simpler version is just using a string compare of daeElement::getTypeName() with the type you are interested in.

-Andy

thanks for your help.

Other inputs with semantics “NORMAL” and “TEXCOORD” are pointing to domSources, only “VERTEX” is pointing to domVertices?

Yes that is the way it is.
Vertices needed a special handling for various reasons, mainly they just need a unique identity that specifying with just position vectors cannot do. For example, two different triangles in different <triangles> elements both reference a point at 0,0,1 … is it the same vertex? is it two different vertices at the same position? Thats pretty much why there is that special handling there.

-Andy