<blah, blah, blah> about 3,000 of them
It turns out that the PUBDEF record loader in this app (written 20+ years ago and virtually unchanged since) used a recursive algorithm to load records where there was an unknown number of repeated subrecords within the main record. It was very elegant. It also fell over dead with stack overrun issues when "n" got large. The 3,000 public's test case can cause "n" to get "large". Modern bloatware apps can cause "n" to get large.
Theoretical elegance, meet harsh reality. Mr. recursion is going to be hitting the unemployment line after all these years in this instance. You can always substitute iteration where recursion was used and I will be doing so here. I suspect the iterative equivalent will be quite a bit faster as well, since it will be more apt to keep L1 cache's from sloshing full of once-used recursive stack data.