Finding the origin of Segmentation faults when opening files

[IM_3311770]

It appears I misposted this in the parametric forum...I hope this is the correct forum now. Cocreate ME10 is Cocreate Drafting, no?

I do systems support for users who use Cocreate and I occasionally have to help them when ME10 reports a 'segmentation fault' when opening a file.

The error is pretty much always due to a value having been written out which cannot be read back in by ME10, "-1#CNAM" is a common one but I've also seen decimals being written out with comma separation rather than dot separation. We are in spain, so the local decimal separator is comma rather than dot (i.e 1,2 rather than 1.2) but that particular error only occurs occasionally.

I'd like to know if there is a either

- a command line tool for validating ME10 files, which I could use to bulk identify files which have errors.

- or a tool which identifies the line number of the block which is causing a problem instead of the useless 'segmentation fault' which is displayed to the user.

We have thousands of drawings, many going back to the 90s so quite a few are probably affected..

I realise that ME10 is a macro based system and what it writes out seems to be linked to each individual macro, but there must be so way to validate the format.

At the moment I open the file in a text editor and bulk remove blocks of the file to locate a particular element which causes a problem. Once identified I remove the element and save the file, but its highly time consuming.

The ME10 installation is currently under support, so we can update to a more recent version or work through the distributor to obtain a tool, if one exists, When I asked some time back they didn't even seem to understand the concept. It appears they've spent years manually looking for format errors for clients and just think thats normal.

Anyone able to help?

[FriedhelmK]

Hello "im_3311770"
To start, I have no patent solution.
This problem is a wide field and you are looking for a solution if it affects an existing drawing.
If this occurs directly when you load the drawing, you have very bad cards.
If it happens later when working, then you can usually help.

For the reasons, I refer to a specialist who was involved in programming.
http://www.clausbrod.de/cgi-bin/view.pl/CoCreateModeling/OsdmFaqTroubleshooting#What_does_the_error_message_Esca
See also the title below
"What does the error message" Signal Received: Segmentation Violation "Mean?"
He writes about Modeling, but in my opinion that also applies to drafting.
> After restarting Cocreate Modeling, Try to Analyze the Model, For Example BY Running the Part Checker in "Verbose Mode".
Unfortunately, I don't know that for ME10 (would be nice).

From here what I would do.
For you if you want to work prophylactically with the existing drawings :
Load all drawings with the CHECK_2D option
and save them with
STORE MI SELECT GLOBAL ALL CONFIRM (if you want DEL_OLD) "File name"
Drafting store only the elements that it knows the rest will be deleted.

For the user:
1. We load ALL DRAWINGS with the CHECK_2D option.
Personal training on the topic and what the effects can be.
If the evil SIGNAL-Message comes, NEVER continue working on the drawing!
He should try to remember which steps he recently carried out in the drawing and to write it down so that he can describe it a week later if you decide to give the case to the support.
Then save the drawing with STORE MI SELECT GLOBAL ALL CONFIRM ( to a new ) "file name".

Leave the corrupt original file where it is. Probably you need it for the support.
Now Shuth Down Drafting/Me10.
After the restart
Load drawing again with LOAD CHECK_2D "File name"
Control whether the last work/changes are still present. If in doubt, delete the last changes and continue working at this point.
If you do this, you have a good chance that the drawing is fine again.

In my opinion, most of these cases were created in versions 9, 9a, 9b. (Think that was the first version with the Windows User Interface)
From this point of view we were lucky.
We were forced to continue working with 8.7G on Unix and only moved to Win NT and ME10 v12 much later.

From another forum (Feb. 2003) ;-):
With us (6 times me10 on NT4), the V9 was only useful with the C-patch in front of the segmentation error. Then he no longer appeared.
The 9a was also unable to work, with the B the error was still very common.
Now with the V10, the error actually never occurs.
Important: If the error occurs, save immediately, end me10, restart me10 and load the drawing (preferably with check_2d). At most without data loss.
But if you push the mistake away and continue working, it goes well 1-2 times and then me10 is dead and can only be shot down with the task manager, then of course with data loss.
Hope this helps a litle

[Kotom-Eng]

Dear @IM_3311770 ,

I am still interested in your experience and I have some questions:

- How did you find that a line containing "-1#CNAM" is the cause of the problem?

- Are there other strings causing the problem (apart comma in dimensions)?

- Can you send a file containing such strings?

[IM_3311770]

The QNAM tag is a known bug, which support informed us about some time back

https://www.ptc.com/en/support/article/cs330494?language=en&posno=15&q=Segmentation%20Error&ProductFamily=CoCreate%20%26%20Creo%20Elements%2FDirect&Product=Creo%20Elements%2FDirect%20Drafting&source=search

There are other bugs which are related to writing decimals, which I found by just examining the files. Its pretty simple but time consuming.

Open the file in notepad++, navigate to about half way through the file to the nearest beginning of block. Select from the beginning of the block to the last block in the file. Delete everything and save the file.

If you can open the file and you still get a segmentation error (you will get other errors due to internal references within the file being missing), we have learned that the error (or an error) is in the first half of the file.

Repeat the process by isolating sections of the file. You can locate errors by removing blocks of 50% of the file, chopping down to ever smaller files, until you end up with a single block as the culprit.

About 8 steps is the max you will need to identify an error. If the file has multiple errors, you will have to repeat the process multiple times. A given error is often repeated throughout the file, so if you can identify what is causing the problem, like commas in decimals, you will need to manually search for cases and remove the blocks, or change ‘,’ to ‘.’

In the end, the cause is sloppy programming and inexistent error recovery.