[Gerbv-devel] Problems with mirroring operations.

[Linda Huxley]

I am working with the latest commit of gerbv. When I load a project
that displays the back side of a board, the pad sizes appear to be
correct. (See screen print: Before.png.) When I mirror all Gerber
layers with "Apply to visible" (from the Edit Layer dialog), some of the
square pads have increased in size, and the solder mask layer is no
longer inverted. (See screen print: Apply_to_visible.png.)

Next, if I reload the project without exiting gerbv, and I use "Apply to
selected" to mirror each layer separately, I end up with much the same
result, except that some of the square pads are even larger. Also, the
solder mask layer remained inverted until I changed the last layer,
.GTL. (See screen print: "Apply_to_selected.png".)

Next if I exit gerbv, reload the project and mirror all of the layers
separately, I don't see any problem at all. This might indicate that
"Apply to visible" is corrupting memory, perhaps overwriting a buffer.
(See screen print: "No_problem.png".)

I saw some other strange behavior, but it wasn't reproducible on demand.

The Gerber files were generated by Kicad.

[Sergey Alyoshin]

Hello, Linda

Can you make simple Gerber file with such problem for testing?

Maybe delete all traces except problem apertures and near traces (to
simplify size change detection) in Gerbv?

I am working with the latest commit of gerbv. When I load a project that
displays the back side of a board, the pad sizes appear to be correct. (See
screen print: Before.png.) When I mirror all Gerber layers with "Apply to
visible" (from the Edit Layer dialog), some of the square pads have
increased in size, and the solder mask layer is no longer inverted. (See
screen print: Apply_to_visible.png.)
Next, if I reload the project without exiting gerbv, and I use "Apply to
selected" to mirror each layer separately, I end up with much the same
result, except that some of the square pads are even larger. Also, the
solder mask layer remained inverted until I changed the last layer, .GTL.
(See screen print: "Apply_to_selected.png".)
Next if I exit gerbv, reload the project and mirror all of the layers
separately, I don't see any problem at all. This might indicate that "Apply
to visible" is corrupting memory, perhaps overwriting a buffer. (See screen
print: "No_problem.png".)
I saw some other strange behavior, but it wasn't reproducible on demand.
The Gerber files were generated by Kicad.

[Linda Huxley]

Hi Sergey,

OK, I'll see what I can do to simplify the problem. I wanted to mention
that I noticed that (for those particular Gerbers) the problem appears
on the square pads on all "8" 3M MDR connectors on that board (4
connectors are 20 pin and 4 are 50 pin). It is highly likely that those
are the only 8 pads with that "aperture" size. So perhaps it is the
aperture table that is being overwritten in that case.

[Linda Huxley]

I didn't get anywhere attempting to pare down the problem. So I went
looking in the code. In "callbacks.c" the routine
"callbacks_change_layer_edit_clicked" does something highly suspect.

transforms = g_new (gerbv_user_transformation_t *,
mainProject->last_loaded +
2 /* layer + NULL */ +
1 /* if selected layer is visible */);

From what I can tell, g_new will allocate an array of pointers to
transformations, without actually allocating any memory for those
transformations. Furthermore those pointers are initialized nowhere.
Code that looks something like the following might work better.

transforms=(gerbv_user_transformation_t **)
malloc(sizeof(gerbv_user_transformation_t *) *
mainProject->last_loaded+3);
if(!transforms)
abort();
transforms[0]=(gerbv_user_transformation_t *)
malloc(sizeof(gerbv_user_transformation_t) *
mainProject->last_loaded+3);
if(!transforms[0])
abort();
for(i=1;i<mainProject->last_loaded+3;++)
transforms[i]=transforms[0]+i;

Post by Linda Huxley
Hi Sergey,
OK, I'll see what I can do to simplify the problem. I wanted to mention
that I noticed that (for those particular Gerbers) the problem appears
on the square pads on all "8" 3M MDR connectors on that board (4
connectors are 20 pin and 4 are 50 pin). It is highly likely that those
are the only 8 pads with that "aperture" size. So perhaps it is the
aperture table that is being overwritten in that case.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Gerbv-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gerbv-devel

[Linda Huxley]

Sorry about that. Please ignore my last post. I'll keep looking.

Post by Linda Huxley
I didn't get anywhere attempting to pare down the problem. So I went
looking in the code. In "callbacks.c" the routine
"callbacks_change_layer_edit_clicked" does something highly suspect.
transforms = g_new (gerbv_user_transformation_t *,
mainProject->last_loaded +
2 /* layer + NULL */ +
1 /* if selected layer is visible */);
From what I can tell, g_new will allocate an array of pointers to
transformations, without actually allocating any memory for those
transformations. Furthermore those pointers are initialized nowhere.
Code that looks something like the following might work better.
transforms=(gerbv_user_transformation_t **)
malloc(sizeof(gerbv_user_transformation_t *) *
mainProject->last_loaded+3);
if(!transforms)
abort();
transforms[0]=(gerbv_user_transformation_t *)
malloc(sizeof(gerbv_user_transformation_t) *
mainProject->last_loaded+3);
if(!transforms[0])
abort();
for(i=1;i<mainProject->last_loaded+3;++)
transforms[i]=transforms[0]+i;

Post by Linda Huxley
Hi Sergey,
OK, I'll see what I can do to simplify the problem. I wanted to mention
that I noticed that (for those particular Gerbers) the problem appears
on the square pads on all "8" 3M MDR connectors on that board (4
connectors are 20 pin and 4 are 50 pin). It is highly likely that those
are the only 8 pads with that "aperture" size. So perhaps it is the
aperture table that is being overwritten in that case.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Gerbv-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gerbv-devel

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Gerbv-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gerbv-devel

[Valerio Messina]

Post by Linda Huxley
Sorry about that. Please ignore my last post. I'll keep looking.

yes, g_new() allocate and cast to the given type

Valerio