How to Continue Running in API after Memory Violation Error at Line 107 of Memory.h
By 'memory violation error', I assume you are getting an access violation exception. And this line (memory.h(107)) would be adsk::core::Ptr<T>::operator->(). This is the inline smart pointer class' dereference operator.
An access violation on this line should mean an problem reading memory at "&Ptr<T>::ptr_", and that should mean that the address of the Ptr<T> variable is bad. Since these smart pointers are most commonly on the call stack as a local variable, this could mean corruption of the call stack, and there is not really an easy or safe way to continue at this point. You would need to identify where the original memory corruption occurred and handle it there somehow.
The other possibility is if this is happening to a Ptr variable that you had referenced in another container (a class or a std container). If that is the case, then you need to determine what happened to the memory of that container.
Kris
Kris Kaplan
I'm not noticing anything obvious in your snippet, but specifically which 'operator->()' call is hitting the exception? In this code, the only one I see is the call to 'ObjectCollection::item'. But from your description, I assume it is happening later when you attempt to use the item, so I would assume in this case it is the 'curve3D' variable.
If it is on the dereference of the curve3D variable immediately after it is returned from the 'item' method, then as mentioned, I would most likely suspect that there was a stack corruption (not specifically related to this item, but caused somewhere else in your code and it just eventually crashes at this point).
You should note that the pointer should have been good when it was returned from the 'item' method, because that is assigning it into a Ptr with a different template type, so it will dereference the raw pointer to query for that type, and do some reference counting. So it appears that the pointer is going bad after this point. If you set a memory address breakpoint on that Ptr's ptr_ variable, you should break at the point it gets stomped on (if that is in fact what is happening).
Also note that plane surface intersection isn't limited to return a Curve3D. It can also result in a Point3D (e.g. when tangent to a point on the surface).
If it is reproducible with a simple sample, then please send the files and the simplified script and we can look at it. It looks like in this case, it should only take a plane, the surface you are intersecting with, and this looping code if it is specific to the surface geometry.
Kris
Kris Kaplan
I'm not seeing anything obvious in there. The only thing might be that you should check the size of IntersectionPtsObjColl before assuming that it has an item(0). If the plane and curve do not intersect, I would expect this to return an empty collection, so item(0) should return null, so the "IntersectionPts[M]->y()" would raise an exception. But if that was the case, it would be the C++ runtime exception we throw from the Ptr-> implementation, not an access violation. But if that is what's happening, then you could just add a null check (if (!IntersectionPts[M])...), or add a try/catch block around this code.
If that is not what this is, then I would need a simplified code sample with simplified geometry data to reproduce this to help further. (Not a full app with a big data set, but something like one plane definition, one curve definition, and the failing intersection code between them.)
Kris
Kris Kaplan
Thurai,
Note that line about exceptions propagated out of the API: In languages like Python, they are raised as exceptions. But in C++ we do not raise these errors as exceptions to allow for 'return value, check last error' type error handling.
However, this does not apply to null pointer dereferences on your side of the API. An API like 'Collection.item' will return a null pointer on something like an index out of range error. The 'last error' will be set, but if your code dereference the Ptr containing the null pointer, it will raise an exception. So you would either need to check the pointer for null, check for the last error, or wrap it in a try catch block (I would recommend just checking the pointer for 'false-ness').
And for a line of code like:
Ptr<adsk::core::Curve3D> curve = planeSurfaceIntersections->item(0);ObjectCollection::item returns a Ptr<Base>, but you are assigning it to a Ptr<Curve3D>. This has to perform a client side call to query<Curve3D>. So in the case that it really returns a Ptr<Point3D>, that query<>() will fail, leaving the 'curve' variable with a null pointer. If you do not check for that null in your code, the dereference will trigger a client side access violation. This has nothing to do with the API throwing an exceptions on errors. This is purely client side. And if you want to catch client side errors (in either interface queries, or missing error handling), then you could add exception handling.
Kris
Kris Kaplan
Moorthy,
Please refer to the C++ Specific Issues in the User's Manual, specifically the 'Handling Errors' and 'Object Types and Casting'. It should specifically address your questions. But basically:
1. To check if a Ptr is null, just check the Ptr for a falsy bool value. E.g.
Ptr<Curve3D> curve = curves.item(i);
if (!curve) ...And no, in those two lines of code, you are not checking the return type of the 'item' method call. In the 'if' condition, you are dereferencing 'IntersectionPts[M]' without ever checking it for null. The 'if' condition is just check if the call to the 'y' property method returned a zero value. But if IntersectionPts[M] contained a nullptr (either because the collection was empty, or did not contain a Point3D type at index 0), the the dereference to call the 'y' method will throw a runtime exception (that would have to be caught and handled if you do not choose to check the pointer value first).
2. Refer to the 'Object Types and Casting' section. But basically, you could just try to cast the object to the desired type and check if it succeeded:
Ptr<Base> obj = curvesOrPts->item(i);
if (Ptr<Point3D> pt(obj)) ...
else if (Ptr<Curve3D> curve(obj)) ...Or you could call the 'objectType' method and switch behavior based on the actual object type. (But switching on objectType is more cumbersome when dealing with polymorphic types. It's usually easier to just try casting to the type you desire as above.)
Kris
Kris Kaplan
Moorthy,
"But Still I would like the lines of code
(1) to check for Null of"
if (IntersectionPts[M])
y = IntersectionPts[M]->y();
"(2) to Catch an Exception in this case."
try {
y = IntersectionPts[M]->y();
} catch(const std::exception& e) {
...
}
Kris
Kris Kaplan
