Patch 111685 breaks string concatenation!!!

Question

Patch 111685 for WS6U2 fixes a lot of problems but introduces a massive memory leak in operator+= for std::string. Sun has already acknowledged that it's a serious bug (bug id 4520126) although they are taking forever to fix it:
This is the test case that we submitted to Sun:
$ uname -a
SunOS mildev1 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-80
$ CC -V
CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-01 2001/08/01
main.cpp
#include <string>
int main()
const char JUNK[] = "JUNK";
std::string s;
for (int i = 0; i < 10000; ++i) s += JUNK;
return 0;
$ CC -staticlib=Crun,Cstd -g main.cpp -o main
$ dbx ./main
Reading main
Reading ld.so.1
Reading libm.so.1
Reading libw.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libc_psr.so.1
(/pkgs/sun_workshop62/bin/../WS6U2/bin/sparcv9/dbx) check -leaks
leaks checking - ON
(/pkgs/sun_workshop62/bin/../WS6U2/bin/sparcv9/dbx) run
Running: main
(process id 17850)
Reading librtc.so
RTC: Enabling Error Checking...
RTC: Running program...
Checking for memory leaks...
Actual leaks report (actual leaks: 9986 total size: 200142024 bytes)
Total Num of Leaked Allocation call stack
Size Blocks Block
Address
====== ====== ========== =======================================
200142024 9986 - operator new < std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__getRep
Possible leaks report (possible leaks: 13 total size: 257934 bytes)
Total Num of Leaked Allocation call stack
Size Blocks Block
Address
====== ====== ========== =======================================
257934 13 - operator new < std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__getRep
execution completed, exit code is 0

Answer 1

The original message here was posted almost a month ago. The response by ForteSupport clearly confirms the existence of the problem, and I have written my own tests. Since the time when this problem was acknowledged, Sun has released patches for Forte C++ 6U2, in the same patch line (111685-03 updates 111685-02. 02 introduces the leak) but that patch does not address the problem.
Memory leaks of any type are not acceptable, but this is a nightmare memory leak: it is in library code and it is triggered by a what is a very common operation (string concatenation) in any sort of web or network services product. These are exactly the type of products that cannot tolerate memory leaks, because they have long uptimes.
This memory leak was introduced in a patch that fixed, among other things, the fact that exceptions were not being caught so that any program that threw an exception aborted. While I find it difficult to understand how problems like these could pass any sort of regression testing, this is not a perfect world, and things do go wrong. But what I find absolutely incomprehensible is that it could take a month to release a fix for this. What is the delay?