Debugging problems is really easy once you "have them under glass". Get all the input data, get all the code, build it on your computer, and you can bisect down on the problem in the debugger until you have fixed it. (Ok. This is an over simplification. Assume that you are really smart, can talk to someone who knows about the code you are looking at, and have an unlimited supply of time and coffee :-).)
In ACIS, journalling really helps with these problems but it has its limitations. Journalling is a feature of ACIS where you can call APIs with a special option setting which tells them to print a scheme script describing the operation, and save a sat file for the inputs. What are the problems? It is time consuming and unusual work to support. (How often to most ACIS programs manipulate strings? The c library for strings is really dangerous which makes this even more fun.) In addition, only APIs are journalled, but customers can all sorts of functionality. There are sg functions which are lower level and generally are not journalled. Then there are call backs (e.g., MESH_MANAGERs) which we don't even try to journal.
I dislike using C++ samples because it consumes a lot of time, but they have their place. Scheme scripts (or JS scripts for CGM Component) can distill a customer situation to just a bunch of solid modelling operations. A sample application often illustrates context. Sometimes an API call that seems to reveal a bug as a scheme script was actually caused by an application trying to do a workflow that doesn't make sense. Experience maintaining a solid modeler gives a person a warped perspective about what is natural.
I write this because I spent the better part of a day debugging a sample application which showed a problem that could have been journalled. I didn't know the problem could have been journalled, because I couldn't reproduce it. I had the sat file and the same code level of ACIS and a description of what the user was trying to do. It turned out that using facet_options_expert rather than facet_options_precise caused a significant change in the answer. Since the customer was using a GLOBAL_MESH_MANAGER that they wrote, I assumed some of the difference in behavior could be caused by that.
I guess it takes practice asking the right questions and getting a little creative about how to debug a problem. What is the craziest thing you have had to do to reproduce a bug?
