Problem with STEP-Export in assembly mode

Hello everyone,

I have a problem using the STEP-Export Facilities of OpenCASCADE 5.2 with references (assembly mode on), to keep the filesize small.
When using more than a few hundred references, the TKXSBASE.dll crashes with a stack overflow.Consider the following simple example program, that writes a square of n*n boxes as references on a grid, where n is the programm argument:

//////////////////////////////////////////////////////////////

//...include all relevant OCC headers here////////////////////

static TopoDS_Compound AddTestStructure(int nCount_)
{
BRep_Builder B;
int nCount=nCount_;
TopoDS_Compound C;
B.MakeCompound(C);
BRepPrimAPI_MakeBox mkBox(1.0, 2.0, 3.0);
for (int i=0; i for (int j=0; j gp_Trsf trsf;
trsf.SetTranslationPart(gp_Vec(5.0*i, 05.0*j, 0.0));
TopLoc_Location topLoc(trsf);
TopoDS_Shape tempShape=mkBox.Shape().Located(topLoc);
B.Add(C, tempShape);
}
}
return C;
}

int main( int argc, char *argv[ ])
{
int nCount = 10;
if (argc > 1)
nCount = atoi(argv[1]);
STEPCAFControl_Writer writer;
Handle_TDocStd_Document document;
document = new TDocStd_Document("Pace Test-StepExporter-");
Handle_XCAFDoc_ShapeTool shapeTool;
shapeTool = XCAFDoc_DocumentTool::ShapeTool(document->Main());
shapeTool->AddShape(AddTestStructure(nCount), Standard_True);
STEPControl_StepModelType mode = STEPControl_AsIs;
if (!Interface_Static::SetIVal("write.step.assembly",1)) { //assembly mode
assert(false && "failed to set assembly mode for step data");
}
try {
if( writer.Transfer(document, mode)) {
IFSelect_ReturnStatus stat =
writer.Write("TestExportStructure.step");
}
} catch (Standard_Failure e) {
cout } catch(...) {
cout }
return 0;
}

////////////////////////////////////////////////////////////////////

The program will work with argument 10 (i.e. 100 cubes) but will crash with
argument 20 (i.e 400 cubes), when the default stack size on
Windows 2000 (i.e. 1MB) is used.
The problem seems to originate from a recursive call of the Handle_Transfer_Binder destructor (each Transfer_Binder owns another Handle_Transfer_Binder field), which causes the stack overflow, but I have not figured out a patch yet.
Has anyone encountered similar problems and has some ideas for a solution?
I would be very interested in your ideas and will post in return any suggestion for a patch that I come up with.

Kai