Infinite recursion in C++ STL?

[Travis Craig]

We are seeing what might be an infinite recursion in the C++ Standard Template Library, or at least a deep recursion. It also might be in a Rogue Wave library. I can try to narrow that down further and add what I find later.

I wonder whether anybody has seen a recursion like this and/or knows of a patch. Here is a piece of the traceback (bear with me; I haven't used this forum system and wonder how the traceback will look). The top line was repeated until the stack overflowed.

. . .
CXXL$RWRSQ18RWRWSTD204RW11H6MJE _RWerase
133784
CXXL$RWRSQ18RWRWSTD204RW11H6MJE _RWerase
133784
CXXL$RWRSQ18RWRWSTD204RW11H6MJE _RWerase
133784
CXXL$ERSQ18RWRWSTD204RWR3QDF976 erase
133799 0000000000000368 000000000061CF18
INDEX1 Load 41018 0000000000037344 0000000000595264
REFRESHTHREAD ReloadIndex 131584

[John Gillings]

Travis,
What is the source code at the deepest point in your program?

[Travis Craig]

John,

Our function load() invokes the clear function on a multimap:

m_subscripts.clear();

where m_subscripts is of type Subscripts:

typedef std::multimap
struct CSubscript
{
int m_area;
int m_category;
int m_location;
Exceptions::iterator m_iter1;
Exceptions::iterator m_iter3;
};

I compiled INDEX1.CPP with a show-all listing to see line 41018 and it was this line from the multimap class declaration in header file map.:

void erase (iterator first, iterator last) { _RWt.erase(first, last); }

Oh, and this information indicates that we were using STL, not Rogue Wave.

--Travis

[Travis Craig]

Time to close this one, I guess. So far, it appears that either limiting processes to a single kernel thread (with SYSGEN parameter MULTITHREAD) or adding more thread safety to the code itself causes the problem to stop occurring. It either shrinks or closes a window that had been opened wider by going from uniprocessors to multiprocessors.

--Travis