Debug Functionality

Contents

• 101.1 Introduction
• 101.2 Checking the validity of the session
• 101.3 Ensuring consistent usage of version control mechanisms
• 101.4 Removing dependence on order of returned arguments
• 101.5 Testing application signal handlers
• 101.6 Monitoring items, classes and function calls
• 101.7 Comparing bodies
• 101.8 Fault reporting

[back to top]

101.1 Introduction

This chapter describes the wide range of debug functions that are provided to help you monitor aspects of your Parasolid implementation. The functionality offered includes, but is not limited to, APIs that can be used to test signal handlers, compare bodies, help maintain consistent version control, and monitor the creation and deletion of objects in your Parasolid session.

Parasolid’s debug functionality should also be used when generating data to send to Parasolid Support. See the Reporting Faults to Parasolid manual for more information on this aspect.

[back to top]

101.2 Checking the validity of the session

You can call PK_DEBUG_SESSION_check to determine the state of the Parasolid session. This is important when, for example, you wish to ensure the session is valid after intercepting and dealing with an error.

By default, all partitions in the session are checked. This can be restricted to specific partitions by using the partitions option.

If your application makes use of partitioned rollback you can roll each partition from its current state to its other states and perform checks. Control over which pmarks are traversed is given by the roll_direction option.

The maximum number of faults that can be returned is set by the max_faults option. See Section 30.2.1, “The number of faults to be returned”, for more information on this option.

[back to top]

101.3 Ensuring consistent usage of version control mechanisms

The following functions can be used to debug your implementation of Parasolid’s version control mechanisms.

See Chapter 116, “Version Controls”, for more information on these systems.

[back to top]

101.4 Removing dependence on order of returned arguments

For the vast majority of modelling and enquiry functions, the order of entities in returned arrays is not guaranteed by Parasolid. As a result of this your application must not rely on the order in which entities are returned from a function.

For example, if an edge blend needed to be reapplied, perhaps as a result of rolling back and then replaying some operations, your application should not expect the orders of the returned arrays to be the same from each PK_BODY_fix_blends call.

The following pair of functions can be used to test whether your application code is relying on the order in which entities are returned by Parasolid.

See Section 10.2.7.2, “Order of entities”, for more information on the order of returned arrays.

[back to top]

101.5 Testing application signal handlers

Parasolid provides the function PK_DEBUG_try_error_handler to help you test signal handlers that you have written for your application. The API calls a function defined in your application from a thread executing within Parasolid. Your function should either create a run-time error or call PK_SESSION_abort, allowing you to test your signal handlers.

The use_protected option can be set to simulate signals generated from protected or unprotected sections of code in Parasolid.

By default, the function passed to PK_DEBUG_try_error_handler is called from the thread that the application used to call into Parasolid. If your application makes use of Symmetric Multi-Processing (SMP), you can use the smp option to call the supplied function from one or more of the SMP worker threads generated by Parasolid. The number of SMP worker threads calling the supplied function is controlled by the call_from_one option, and the timing of their calls is controlled by the use_locks option.

See Chapter 121, “Signal Handling”, for further details on writing signal handlers.

[back to top]

101.6 Monitoring items, classes and function calls

The functions in this section allow you to monitor the creation and deletion of objects in your Parasolid session, and the entry into and exit from an array of PK functions. You can supply a pair of callbacks (one for each event being monitored) to each function. The appropriate callback is invoked whenever its associated event occurs.

Objects can be monitored using either PK_DEBUG_SESSION_watch_items or PK_DEBUG_SESSION_watch_classes. If you know the session tags of the objects you wish to monitor, you can pass arrays of these tags to PK_DEBUG_SESSION_watch_items. If you do not know the tags or you wish to monitor an unknown number of objects, you can pass arrays of PK_CLASS_t tokens to PK_DEBUG_SESSION_watch_classes.

[back to top]

101.7 Comparing bodies

The differences between a pair of similar bodies are found by calling PK_DEBUG_BODY_compare. This can be used when comparing the results of alternative modelling workflows or to ensure that a legacy part is updated consistently.

By default, PK_DEBUG_BODY_compare performs only global comparison tests between the bodies. These are comparisons of the numbers of topologies on each body and are far faster than comparing underlying geometries. You should take care to avoid “false negatives” when using only global comparisons. For example, a solid sphere and solid non-self-intersecting torus are topologically identical and are found to have no global differences, but they are geometrically different. For such cases, the local differences between the parts should also be identified.

Local comparisons are enabled by setting the max_diffs option to a positive integer. When enabled, Parasolid undertakes a more computationally expensive set of tests, in which it matches face pairs on the bodies then analyses each pair for topological and geometric differences. Comparisons continue until max_diffs matched pairs have been identified as non-identical, or all pairs have been analysed.

For an example of this functionality, see the code example in the C++\Code Examples\Inquiries\Model Analysis\Body Compare folder, located in example_applications in your Parasolid installation folder.

[back to top]

101.8 Fault reporting

To help generate the appropriate data when contacting Parasolid Support to report a fault or make an enquiry, the following functions are provided.

See the Reporting Faults to Parasolid manual for more information on generating fault reports.

For an example of this functionality, see the code example in the C++\Code Examples\Application Support\Archiving\Journal Debug Report Session folder, located in example_applications in your Parasolid installation folder.

[back to top]