CGAL users discussion list

[Costas Tsirogiannis <>]

I just found the mistake, a really stupid one: I was passing the
polyhedron object through the function not as "Polyhedron &plh" but
as "Polyhedron plh" and after subsequent calls the handles were just pointing somewhere in the
containers of a Polyhedron object that died after the end of the function scope.

Thanks for insisting that the error had to do with some
copy/initialization issue. If it was not for that I would just think
that there was an inherent problem with the Handle concept.

thanks!

On Thu, Jul 8, 2010 at 8:04 AM, Sebastien Loriot (GeometryFactory) <sloriot.ml@gmail.com> wrote:

Hello,

I could no reproduce the error you describe with the following code:


#include <CGAL/Delaunay_triangulation_3.h>
#include <CGAL/Simple_cartesian.h>

typedef CGAL::Simple_cartesian<double> Kernel;
typedef CGAL::Delaunay_triangulation_3<Kernel> T;

class Myclass {
private:
 T::Vertex_handle _h;
public:
 void set_handle( T::Vertex_handle &h)
 { _h = h;}

 T::Vertex_handle

 get_handle(void)
 { return _h;}
};

void A( Myclass &mc,T::Vertex_handle hndl)
{
 mc.set_handle(hndl);
 T::Vertex_handle hndl2 = mc.get_handle();
 std::cout << &(*hndl2) << std::endl;
}

void B( Myclass &mc)
{
 T::Vertex_handle hndl3 = mc.get_handle();
 std::cout << &(*hndl3) << std::endl;
}


int main()
{
 Myclass mc;
 T t;
 t.insert(Kernel::Point_3(1,2,3));
 t.insert(Kernel::Point_3(3,2,3));
 t.insert(Kernel::Point_3(1,2,4));
 t.insert(Kernel::Point_3(2,2,3));
 {
   T::Vertex_handle v=t.insert(Kernel::Point_3(24,12,3));
   A(mc,v);
 }

 B(mc);

 return 0;
}

I think this should be a problem of copy/initialization somewhere in your code. A handle is an iterator over the compact container so there
should be no problem to make a copy.

S.



Costas Tsirogiannis wrote:

 I checked if there is any member object that is not assigned properly but there is no issue there.

 Here's where I think the problem is:

Assume that you have class that stores a member handle

class Myclass {
....

private:

Kind_of_handle _h;

public:

void set_handle( Kind_of_handle &h)
{ _h = h;}

Kind_of_handle
get_handle(void)
{ return _h;}

} ;


* Assume you have two subsequent calls of some functions A() , B() :

int main(){

Myclass mc;

A(mc);
B(mc);

return 0;
}


void A( Myclass &c)
{
Kind_of_handle hndl;
....
mc.set_handle(hndl);
Kind_of_handle hndl2 = mc.get_handle();
std::cout << hndl2->info() << std::endl;
}

void B( Myclass &c)
{
Kind_of_handle hndl3 = mc.get_handle();
std::cout << hndl3->info() << std::endl;
}

What happens to me is that the std::cout in function A works fine
while the std::cout in function B returns a segmentation fault.

It seems that copying a handle h1 to another handle  h2 is ok
until the scope of h1 is over. After that h2 is not reliable.
Does this make sense? If yes, how do I go around it?
Whether these handles are stored in objects or not does not seem
to be an issue that creates this error.

thanks

Constantinos



 

On Tue, Jul 6, 2010 at 11:05 PM, Sebastien Loriot (GeometryFactory) <sloriot.ml <http://sloriot.ml>@gmail.com <http://gmail.com>> wrote:

   Costas Tsirogiannis wrote:

        I have not defined a copy constructor for the augmented
       half-edges, would that change something here?

   So no, the default should be fine.



       On Tue, Jul 6, 2010 at 3:31 PM, Sebastien Loriot
       (GeometryFactory) <sloriot.ml <http://sloriot.ml>

       <http://sloriot.ml>@gmail.com <http://gmail.com>
       <http://gmail.com>> wrote:

          Did you define a copy constructor and forget to copy the object?
          I think in your case, you should use a boost::Variant as the
       number of
          possible types is only 2.



          Costas Tsirogiannis wrote:


              Here's scraps of code that are indicative of the situation:

              * In the augmented halfedge class I store a CGAL::Object that
              contains
              * a handle, it could be either a face handle or an edge
       stored
              in it:

              Object  _corresponding_triangulation_object;

              * And the member functions that make use of it are:

               bool overlaps_with_triangulation_edge(void)
               { bool temp = _corresponding_triangulation_object.template
              is<Triangulation_face_handle>();
                return !temp; }
               void set_corresponding_triangulation_object( Object &obj )
               { _corresponding_triangulation_object = obj; }

               template< typename Triangulation_item >
               void set_corresponding_triangulation_object(
       Triangulation_item
              &t_item )
               { _corresponding_triangulation_object =
              Construct_object()(t_item); }

               Object& corresponding_triangulation_object(void)
               { return _corresponding_triangulation_object; }                 * So let's say that at some point some function "A"  is
       called
              where it does this:

              Halfedge_handle current_ph;

              **** do something with current_ph ****

               Halfedge_handle   target_ph, old_ph;

              target_ph = fnwk.surface_polyhedron().split_edge(
       current_ph );
              target_ph->vertex()->point() = p;

               old_ph = target_ph->next();
                      target_ph->set_corresponding_triangulation_object(current_ph->corresponding_triangulation_object());
                                       CGAL_assertion(target_ph->overlaps_with_triangulation_edge());
                      target_ph->opposite()->set_corresponding_triangulation_object(current_ph->opposite()->corresponding_triangulation_object());
                      CGAL_assertion(target_ph->opposite()->overlaps_with_triangulation_edge());
                      old_ph->opposite()->set_corresponding_triangulation_object(current_ph->opposite()->corresponding_triangulation_object());

              * Up to here everything is executed ok. But in the following
              code, after the execution
              *of "A" is done, when I traverse the polyhedron face that
              contains the above halfedges I get *segmentation faults
        either
              in the std::cout line or in the line where
              *->overlaps_with_triangulation_edge() is called.


              Halfedge_handle other_ph = ..... ;
              Triangulation_edge entry_te = ..... ;
              Triangulation_edge current_te = entry_te;

              while( !(other_ph->overlaps_with_triangulation_edge()) ||
              current_te == entry_te )
               {
                  std::cout << " other_ph->vertex : "<<
               other_ph->vertex()->point() << std::endl;

                 other_ph = other_ph->next();

                 if(other_ph->overlaps_with_triangulation_edge())
                   CGAL::assign(current_te,
              other_ph->corresponding_triangulation_object() );
               }

               I think there is no problem with accessing the vertex point,
              the memory error
              has to do with the triangulation handles stored as objects in
              the halfedges.

              thanks

              Constantinos




              On Tue, Jul 6, 2010 at 7:48 AM, Sebastien Loriot
              (GeometryFactory) <sloriot.ml <http://sloriot.ml>
       <http://sloriot.ml>
              <http://sloriot.ml>@gmail.com <http://gmail.com>
       <http://gmail.com>
              <http://gmail.com>> wrote:

                 Costas Tsirogiannis wrote:

                     Greetings,

                     I have a problem with run-time errors coming from an
              unorthodox
                     use of handles:

                      I make use of a triangulation and of an augmented
              polyhedron_3
                     object. This augmented polyhedron
                     is a refinement of the surface represented by the
              triangulation
                     : as some algorithm goes on, new edges
                     are added on what used to be the triangular faces.
       It is
                     important that the halfedges,faces and vertices
                     on the polyhedron that originate from features of the
                     triangulation should point to the corresponding
       triangulation
                     features.  Thus each feature stores a handle of
       the original
                     triangulation object: a polyhedron vertex stores a
       handle
                     to the original triangulation vertex of the same
              coordinates, a
                     halfedge stores a handle to the triangulation edge or
                     face on which it lies etc.
                      When a feature is refined eg a halfedge is split,
       these
              stored
                     handles of triangulation features are copied to
                     the newly created features. And then segmentation
       faults
              appear.

                 What do you use to split halfedges ? (the underlying
       question
              being how
                 your handles are set)


                     Specifically, things go wrong when there is an attempt
                     to access the handle member object of the new feature
              outside of
                     the function that created the feature (and copied the
                     handle object to it).  Any ideas for what could
       fix this?

                     thanks

                     Constantinos



                 --     You are currently subscribed to cgal-discuss.
                 To unsubscribe or access the archives, go to
                 https://lists-sop.inria.fr/wws/info/cgal-discuss




          --     You are currently subscribed to cgal-discuss.
          To unsubscribe or access the archives, go to
          https://lists-sop.inria.fr/wws/info/cgal-discuss




   --     You are currently subscribed to cgal-discuss.
   To unsubscribe or access the archives, go to
   https://lists-sop.inria.fr/wws/info/cgal-discuss

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://lists-sop.inria.fr/wws/info/cgal-discuss