#254 heap corrupted when making sketch with nurb segment

crash or data loss
closed-fixed
5
2010-05-26
2010-04-20
No

I'm trying to create a simple sketch containing a linear nurb segment but I keep getting a heap corrupted exception in mk_sketch(). If I replace the nurb segment with a bezier- or linear segment it runs without problem. Is there something wrong with my input data or is this a bug? I have tracked the exception down to the statement bu_free_external( &body ) in rt_db_cvt_to_external5(). I am using brlcad-7.14.8 on Windows XP.

The code I use to initialize the nurb is as follows:

point_t V;
vect_t u_vec, v_vec;
struct rt_sketch_internal *skt;
struct nurb_seg *nsg;

VSET( V, 0, 0, 0 );
VSET( u_vec, 1, 0, 0 );
VSET( v_vec, 0, 1, 0 );

skt = (struct rt_sketch_internal *)bu_calloc( 1, sizeof( struct rt_sketch_internal ), "sketch" );
skt->magic = RT_SKETCH_INTERNAL_MAGIC;
VMOVE( skt->V, V );
VMOVE( skt->u_vec, u_vec );
VMOVE( skt->v_vec, v_vec );
skt->vert_count = 5;
skt->verts = (point2d_t *)bu_calloc( skt->vert_count, sizeof( point2d_t ), "verts" );
for ( int i=0; i<skt->vert_count; i++ )
{
point2d_t p;
p[0]= 10*i;
p[1] =(i%2)*10;
VMOVE_2D(skt->verts[i], p);
}

skt->skt_curve.seg_count = 1;
skt->skt_curve.reverse = (int *)bu_calloc( skt->skt_curve.seg_count, sizeof( int ), "reverse" );
skt->skt_curve.segments = (genptr_t *)bu_calloc( skt->skt_curve.seg_count, sizeof( genptr_t ), "segs" );
nsg = (struct nurb_seg*)bu_calloc( 1, sizeof( struct nurb_seg ), "nurbs" );
nsg->magic = CURVE_NURB_MAGIC;
nsg->order = 2;
nsg->c_size = 5;
nsg->ctl_points = (int *)bu_calloc( nsg->c_size, sizeof( int ), "cv" );
nsg->ctl_points[0] = 0;
nsg->ctl_points[1] = 1;
nsg->ctl_points[2] = 2;
nsg->ctl_points[3] = 3;
nsg->ctl_points[4] = 4;
nsg->pt_type = RT_NURB_MAKE_PT_TYPE( 2, RT_NURB_PT_XY, false );
nsg->k.magic = NMG_KNOT_VECTOR_MAGIC;
nsg->k.k_size = 5;
nsg->k.knots = (fastf_t *)bu_calloc( nsg->k.k_size, sizeof( fastf_t ), "knots" );
nsg->k.knots[0] = 0;
nsg->k.knots[1] = 1;
nsg->k.knots[2] = 2;
nsg->k.knots[3] = 3;
nsg->k.knots[4] = 4;
skt->skt_curve.segments[0] = (genptr_t)nsg;
skt->skt_curve.reverse[0] = 0;
mk_sketch(this->wdbp, name.c_str(), skt );

Regards,
Östen Lundahl

Discussion

  • Sean Morrison

    Sean Morrison - 2010-04-22
    • labels: 622293 --> Geometry Editing
     
  • Sean Morrison

    Sean Morrison - 2010-04-22

    This does indeed sound like a bug, so moved from support request tracker to bugs. That said, while this specific bug can be fixed, you should know that support for NURBS sketch objects will still be limited.

    I doubt you'll be able to perform various operations on them such as extrude or revolve them, and I doubt they'll raytrace too. Their implementation as a 2D primitive is incomplete (help is welcome). I'll see if I can pinpoint the cause of this particular crash, as that should never happen regardless.

    What are you trying to do with them?

     
  • Sean Morrison

    Sean Morrison - 2010-04-22
    • assigned_to: nobody --> brlcad
    • milestone: --> crash or data loss
    • status: open --> open-accepted
     
  • Sean Morrison

    Sean Morrison - 2010-04-22

    Your code also looks *very* familiar to me... did I help you get set up with programmatically creating sketches? or maybe one of the other devs?

     
  • Sean Morrison

    Sean Morrison - 2010-04-22
    • status: open-accepted --> pending-works-for-me
     
  • Sean Morrison

    Sean Morrison - 2010-04-22

    For what it's worth, your sample code compiled cleanly and produced a valid sketch with a NURBS curve:

    mged> l sketch
    sketch: 2D sketch (SKETCH)
    V = (0 0 0), A = (1 0 0), B = (0 1 0)
    5 vertices
    Vertices:
    0-(0 0) 1-(10 10) 2-(20 0)
    3-(30 10) 4-(40 0)

    Curve:
    NURB Curve:
    order = 2, number of control points = 5
    starts at (0 0)
    ends at (40 0)
    knot values are 0 to 4

    So the problem is either A) elsewhere in your code, B) platform specific, or C) already fixed. I'd suggest narrowing down those options and eliminating option C by either using the latest svn sources (7.16.7) or last STABLE branch release (7.16.6).

     
  • Östen Lundahl

    Östen Lundahl - 2010-04-22

    I have tried 7.16.6 but with the same result, and I don't think it is any error elsewhere in the code, because it works for other types of segments. However, since I will not be able to extrude the nurb I will have to find a workaround anyway. What I want to accomplish is to draw closed 2D spline curves and then extrude them and perform booelan operations on the extrusions. I guess I will have to convert the spline into one of the other segment types available. Are there any performance gains using bezier segments compared to line segments in this case, e.g during extrusion and tesselation?

    No, I am not Oscar and not working for him. :) So any similarities in the code are purely coincidental. I'm new to brlcad and have just been looking at the examples and the brlcad source code.

     
  • Östen Lundahl

    Östen Lundahl - 2010-04-22
    • status: pending-works-for-me --> open-works-for-me
     
  • Sean Morrison

    Sean Morrison - 2010-04-22

    You should be able to convert and preserve NURBS curves with a piecewise decomposition into Bezier curves. Line curves will naturally run slightly faster, but then you're not going to have a smooth result without a whole lot of them. The difference is minor, I would just use Bezier curves. Alternatively, you could implement any missing NURBS curve functionality you need. ;)

    The bug you hit must be some subtle initialization, memory, or stack issue given it works just fine here. If you can provide a stack trace, I'll dig further, otherwise I'll just chalk this issue to look into later when someone improves the sketch 2D NURBS curves support.

     
  • Sean Morrison

    Sean Morrison - 2010-04-22
    • status: open-works-for-me --> pending-works-for-me
     
  • SourceForge Robot

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • SourceForge Robot

    • status: pending-works-for-me --> closed-works-for-me
     
  • Sean Morrison

    Sean Morrison - 2010-05-11
    • status: closed-works-for-me --> pending-works-for-me
     
  • Sean Morrison

    Sean Morrison - 2010-05-11

    Last call for a stack trace?

     
  • SourceForge Robot

    • status: pending-works-for-me --> closed-works-for-me
     
  • SourceForge Robot

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • Sean Morrison

    Sean Morrison - 2010-05-26

    This bug was identified, isolated, and fixed by Östen in sf bug report 3007466. Change applied as of r39474.

     
  • Sean Morrison

    Sean Morrison - 2010-05-26
    • status: closed-works-for-me --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks