#254 heap corrupted when making sketch with nurb segment

crash or data loss
closed-fixed
Sean Morrison
5
2010-05-26
2010-04-20
Östen Lundahl
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
     
  • 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).

     
    • 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?

     
    • status: pending-works-for-me --> closed-works-for-me
     
  • 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