On 09/06/12 19:54, Martin Sebor wrote:
I'm not sure how easily we can do that. Almost all of locale
is initialized lazily. Some of the layers might depend on the
facets being initialized lazily as well. This was a deliberate
design choice. One of the constraints was to avoid dynamic
initialization or allocation at startup. [...]
There would be a performance degradation. IMHO, it would be minor and would
simplify the code considerably.
After finally being able to reproduce the defect with SunPro 12.3 on x86_64 I
tried to remove the lazy initialization and a (smaller) test case now passes. I
am attaching the program and the numpunct patch.
Out of curiosity, does it still work if you move the locale into
the thread function? Like this:
I created the test case because I wanted something more specific and with more
predictable results. Initially, the locale object was created in the thread and
it was passing.
Also, does the 27.objects test pass with this patch?
Will try. I don't think that we can actually use this patch, I bundled it with
the test so that people can test the approach right away.
I don't know if we have tests for it but writing to cerr/cout
in a bad_alloc handler should succeed. I.e., this should not
abort:
try {
struct rlimit rlim = { };
getrlimit (RLIMIT_DATA, &rlim);
rlim.rlim_cur = 0;
setrlimit (RLIMIT_DATA, &rlim);
for ( ; ; ) new int;
}
catch (bad_alloc) {
cout << "caught bad alloc: << 123 << '\n';
}
I see..
Liviu
