review - PR253655 Application Error during the use of the FCF and Autofeature

huangyhg

Application Error during the use of the FCF and Autofeatures.

<< Domenico Varacalli  --  03/05/08  13:53:44>>
The sequence of the operations for which the problem happens is not always the same.
In general this happens when I open a window of an already existing feature (FCF or Autofeature).
In this example the error happens when I press the button OK of confirmation, and PC-DMIS it performs the updating  of the whole program,
visualizing the blue scroll bar (1.GIF). However quickly working with the FCF and the Autofeatures, this type of crash appears with an elevated frequency.
In the ZIP file there are the debug data and the video.
<<END>>

<< Changes made by Neil Kay -- 07/23/08  16:28:38>>
Action:  Paola Pallo to Yanhua Huang
<<END>>
<< Changes made by Neil Kay -- 07/23/08  15:22:57>>
Action:  David Petrizze to Paola Pallo
<<END>>
<< Don Turcotte  --  03/17/08  16:56:25>>
I fixed two issues:
1.  F9 on feature, then OK, F9 on FCF, then crash.
2.  Delete Simultaneous evaluation, then F9 on feature, then crash.
The issue of the two messages for "Do you want to update nominals of related dimensions?" when F9 on feature, then OK, has been filed as PR#253846.
Fixed in V43B and V44B.
Files inserted to server
------------------------
V43B\DIMENS\FEATCTRLFRM.CPP
V43B\INCLUDE\FEATCTRLFRM.H
V44B\DIMENS\FEATCTRLFRM.CPP
V44B\INCLUDE\FEATCTRLFRM.H
<<END>>
<< Changes made by Don Turcotte -- 03/17/08  16:57:16>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Don Turcotte  --  03/14/08  17:12:28>>
I think I have fixed the crash that occurs when you F9 on a featue, then F9 on an FCF.  The FCF method ConvertAxesLists(...) was executing the drf alignment at a point where it was unnecessary and inappropriate.  I will test this again Monday to be sure since it is sometimes difficult to get the crash.  I was able to crash in both debug and release builds but not always with the exact same scenario, sometimes the crash occurs only after more F9 activity.
I discovered another scenario which crashes : delete the simultaneous evaluation command, the F9 on a feature and OK.  I will also look at this again Monday.
<<END>>
<< Don Turcotte  --  03/13/08  17:18:49>>
Not setting the EXECUTING bit in FCF executeprivate(...) when the FCF is part of a simultaneous evaluation and executeprivate(...) is called from create_text(...) did not correct the crash although this seems to be a correct change.  This does not crash in the debug build but does crash in release build.  I have traced this to the simultaneous evaluation command do_math(...).  Still looking...
<<END>>
<< Don Turcotte  --  03/12/08  17:18:47>>
All the FCFs are part of a Simultaneous Evaluation command.  This problem seems to be related to the fact that executeprivate(...) for an FCF that is part of a Simultaneous Evaluation command just sets the EXECUTING bit since the Simultaneous Evaluation command actually handles the execution of the FCFs.  The problem comes from create_text(...) of the FCF which calls executeprivate(...).  So when you F9 on the FCF and press OK, the call to create_text(...) will call executeprivate(...) which will set the EXECUTING bit.  But nobody ever clears the bit.  I added a check for step_number equal to DIMCREATETEXT in the executeprivate so the EXECUTING bit won't get set by a call to create_text(...).  This seems to have resolved the crash, but I am still testing.  Maybe when create_text(...) calls executeprivate(...), the FCF should behave as if it is not part of a simultaneous evaluation?
<<END>>
<< Antonella Cravero  --  03/06/08  17:43:56>>
Using the Debug|Win32 version of V43R, I can reproduce the problem both On Line and Off Line. I simply edit (F9) Auto Circle Commands present in the Part Program "GDT_ALL_V02_C.PRG" (ex. CIR4, CIR5, ? and close the dialog (clicking OK), without changing any parameters. The message "Do you want to update nominals of related dimensions?" appears two times and I answer "No" both times. The error appears after the second time I answer "No" and the code where it happens is CPCDstart_align::do_math(void), at line "machine_to_parts=init_id->get_alignment(MACHINETOPARTS);" because of a not valid "init_id" object.
I'll upload Output, Call Stack, ?information inside "v43r_Debug_03-06-08.zip"
Hope this helps. Let me know if I have to do something ...
<<END>>
<< Domenico Varacalli  --  03/06/08  13:24:05>>
More information:
I have repeated a sequence briefer and the problem happens equally, with last version V4.3RC, March 5, 2008.
The problem doesn't happen immediately, when I open for the first time the program (PRG program from file 253655.ZIP).
But when the crash appears for a couple of times, then the frequency of this event is more raised. As if in the PRG program or in his parameters
an anomalous condition is saved, or the system remains under unstable conditions. In the new ZIP file 253655_2.ZIP there are the PRG program
after the crash and the files of configuration. When the crash appears the blue scroll bar is always to 89% (more or less). To look at the new short video.
<<END>>
<< Tim Wernicke  --  03/05/08  08:28:30>>
I cannot reproduce this.  Can you Don?
<<END>>
<< Changes made by Tim Wernicke -- 03/05/08  08:28:31>>
Priority:  to Critical
<<END>>