Reference to uninitialize d object variable [5.11]

Am 25.04.2016 um 09:39 schrieb Leo:

Yesterday I was fiddling around with an ulp to create a more complete FATF

file. Needless to say, it had 'some' typos... :roll:

 

When it finally started, I got (in the midst of processing) this message:

Reference to uninitialized object variable.

The line referred to is part of a loop that had already executed several

times without a problem, so I am at a loss here. To be more precise: the

processing of contact references on a net.

The design checks OK in both ERC and DRC, apart from some minor issues with

angles and such.

 

To check the data, I started another ulp (attached) on the same board to

find the culprit and got the same error message (at line 253), again while

processing contact references on that same net...

 

What causes this message, and more importantly, how do I solve it?

 

Do you get this message in all board files you tried or only in

one board file?

Maybe the problem is not in the ULP, but in the EAGLE file's data

strucutre. In the older binary data it could happen that some

objects were not deleted correctly or maybe some objects were pasted

incorrectly....

You could try to do a GROUP/CUT and PASTE into a new file and try to

run the ULP again. Hope it helps....

--

Mit freundlichen Gruessen / Best regards

Richard Hammerl

  CadSoft Support -- hotline@cadsoft.de

  FAQ: http://www.cadsoft.de/training/faq/

Am 25.04.2016 um 09:39 schrieb Leo:

Yesterday I was fiddling around with an ulp to create a more complete FATF

file. Needless to say, it had 'some' typos... :roll:

 

When it finally started, I got (in the midst of processing) this message:

Reference to uninitialized object variable.

The line referred to is part of a loop that had already executed several

times without a problem, so I am at a loss here. To be more precise: the

processing of contact references on a net.

The design checks OK in both ERC and DRC, apart from some minor issues with

angles and such.

 

To check the data, I started another ulp (attached) on the same board to

find the culprit and got the same error message (at line 253), again while

processing contact references on that same net...

 

What causes this message, and more importantly, how do I solve it?

 

Do you get this message in all board files you tried or only in

one board file?

Maybe the problem is not in the ULP, but in the EAGLE file's data

strucutre. In the older binary data it could happen that some

objects were not deleted correctly or maybe some objects were pasted

incorrectly....

You could try to do a GROUP/CUT and PASTE into a new file and try to

run the ULP again. Hope it helps....

--

Mit freundlichen Gruessen / Best regards

Richard Hammerl

  CadSoft Support -- hotline@cadsoft.de

  FAQ: http://www.cadsoft.de/training/faq/

On 25.04.2016 09:39, Leo wrote:

Yesterday I was fiddling around with an ulp to create a more complete FATF

file. Needless to say, it had 'some' typos... :roll:

 

When it finally started, I got (in the midst of processing) this message:

Reference to uninitialized object variable.

The line referred to is part of a loop that had already executed several

times without a problem, so I am at a loss here. To be more precise: the

processing of contact references on a net.

The design checks OK in both ERC and DRC, apart from some minor issues with

angles and such.

 

To check the data, I started another ulp (attached) on the same board to

find the culprit and got the same error message (at line 253), again while

processing contact references on that same net...

 

What causes this message, and more importantly, how do I solve it?

 

I know there used to be some bugs causing "null" objects on contacts.

Line 253 says:

printf("  CONTACTREF \"%s\"-\"%s\"\n",C.element.name,C.contact.name);

If you add if(C.element && C.contact) do this, it might work.

On 25.04.2016 09:39, Leo wrote:

Yesterday I was fiddling around with an ulp to create a more complete FATF

file. Needless to say, it had 'some' typos... :roll:

 

When it finally started, I got (in the midst of processing) this message:

Reference to uninitialized object variable.

The line referred to is part of a loop that had already executed several

times without a problem, so I am at a loss here. To be more precise: the

processing of contact references on a net.

The design checks OK in both ERC and DRC, apart from some minor issues with

angles and such.

 

To check the data, I started another ulp (attached) on the same board to

find the culprit and got the same error message (at line 253), again while

processing contact references on that same net...

 

What causes this message, and more importantly, how do I solve it?

 

I know there used to be some bugs causing "null" objects on contacts.

Line 253 says:

printf("  CONTACTREF \"%s\"-\"%s\"\n",C.element.name,C.contact.name);

If you add if(C.element && C.contact) do this, it might work.

On 25.04.2016 09:39, Leo wrote:

Yesterday I was fiddling around with an ulp to create a more complete FATF

file. Needless to say, it had 'some' typos... :roll:

 

When it finally started, I got (in the midst of processing) this message:

Reference to uninitialized object variable.

The line referred to is part of a loop that had already executed several

times without a problem, so I am at a loss here. To be more precise: the

processing of contact references on a net.

The design checks OK in both ERC and DRC, apart from some minor issues with

angles and such.

 

To check the data, I started another ulp (attached) on the same board to

find the culprit and got the same error message (at line 253), again while

processing contact references on that same net...

 

What causes this message, and more importantly, how do I solve it?

 

I know there used to be some bugs causing "null" objects on contacts.

Line 253 says:

printf("  CONTACTREF \"%s\"-\"%s\"\n",C.element.name,C.contact.name);

If you add if(C.element && C.contact) do this, it might work.

Thanks for the replies so far, it was both helpful and giving insight.

No amount of cutting/pasting would resolve the issue, even a complete(?)

removal of the offending net and connected parts did not help. Apparently

there remained some sort of a stub...

The check that Morten suggested circumvents the problem: no more crash.

It generates however an 'empty' net reference that will most likely cause

problems in the FATF output of the original ulp. But with the problem now

identified, that is an easy fixable problem.

I'd rather fix the source of the mayhem though, but the binary pcb format

presents a major hurdle in this endeavour.

Oh well, just another reason to upgrade I guess...

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Thanks for the replies so far, it was both helpful and giving insight.

No amount of cutting/pasting would resolve the issue, even a complete(?)

removal of the offending net and connected parts did not help. Apparently

there remained some sort of a stub...

The check that Morten suggested circumvents the problem: no more crash.

It generates however an 'empty' net reference that will most likely cause

problems in the FATF output of the original ulp. But with the problem now

identified, that is an easy fixable problem.

I'd rather fix the source of the mayhem though, but the binary pcb format

presents a major hurdle in this endeavour.

Oh well, just another reason to upgrade I guess...

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Thanks for the replies so far, it was both helpful and giving insight.

No amount of cutting/pasting would resolve the issue, even a complete(?)

removal of the offending net and connected parts did not help. Apparently

there remained some sort of a stub...

The check that Morten suggested circumvents the problem: no more crash.

It generates however an 'empty' net reference that will most likely cause

problems in the FATF output of the original ulp. But with the problem now

identified, that is an easy fixable problem.

I'd rather fix the source of the mayhem though, but the binary pcb format

presents a major hurdle in this endeavour.

Oh well, just another reason to upgrade I guess...

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

On 25.04.2016 14:26, Leo wrote:

Thanks for the replies so far, it was both helpful and giving insight.

 

No amount of cutting/pasting would resolve the issue, even a complete(?)

removal of the offending net and connected parts did not help. Apparently

there remained some sort of a stub...

 

The check that Morten suggested circumvents the problem: no more crash.

It generates however an 'empty' net reference that will most likely cause

problems in the FATF output of the original ulp. But with the problem now

identified, that is an easy fixable problem.

 

I'd rather fix the source of the mayhem though, but the binary pcb format

presents a major hurdle in this endeavour.

Oh well, just another reason to upgrade I guess...

 

The source of the problem is here: 5.11 Time to upgrade?

I made a script to remove null objects in 6.x, but cant remember if the

clr/setgroup commands worked in 5.x.. Prob not. Anyway, I attach my script.

You may find some very old threads written by me how to get rid of them

them in 5.x... But my memory has faded.. I think it may involve some

manual operations, like routing a dummy net to the contact and delete it

again.

On 25.04.2016 14:26, Leo wrote:

Thanks for the replies so far, it was both helpful and giving insight.

 

No amount of cutting/pasting would resolve the issue, even a complete(?)

removal of the offending net and connected parts did not help. Apparently

there remained some sort of a stub...

 

The check that Morten suggested circumvents the problem: no more crash.

It generates however an 'empty' net reference that will most likely cause

problems in the FATF output of the original ulp. But with the problem now

identified, that is an easy fixable problem.

 

I'd rather fix the source of the mayhem though, but the binary pcb format

presents a major hurdle in this endeavour.

Oh well, just another reason to upgrade I guess...

 

The source of the problem is here: 5.11 Time to upgrade?

I made a script to remove null objects in 6.x, but cant remember if the

clr/setgroup commands worked in 5.x.. Prob not. Anyway, I attach my script.

You may find some very old threads written by me how to get rid of them

them in 5.x... But my memory has faded.. I think it may involve some

manual operations, like routing a dummy net to the contact and delete it

again.