Memory leak after C++ exception

[Till Straumann]

I looked into the RTEMS gthread support implementation
and I didn't like too much what I saw:

a)  it uses task variables :(
b)  it leaks memory, indeed. The destructor is never called
     and the memory allocated for the task variable doesn't seem
     to be released either (probably not a big problem).

The implementation with task variables is not satisfactory and
hard to understand. Also, a task variable doesn't behave exactly
like a gthread key. It isn't created along with a task and doesn't
die with it (--> if you call gxx_key_delete, there may still
be threads around using the task variable related to the key).

IMO, it would be desirable to have a few fields in the libc reent
structure for supporting this kind of things (including 'privateenv'
and 'rpc context' pointers).

d)  BTW: The gthread_once() implementation could also be improved:
     It disables task preemption around the callback function
     which doesn't seem necessary.

===> I propose an overhaul of cpukit/libcsupport/src/gxx_wrappers.c

-- Till

(Didn't file a PR because I don't consider the attached [untested!]
patch a permanent solution)

Valery Pykhtin wrote:
> Hi all,
> 
> I detected memory leak dealing with C++ exceptions. The sympthoms are
> following:
> 
> 1. start new task
> 2. do smth
> 3. throw
> 4. catch
> 5. task selfdeletes
> 6. Memory leak ! The chunk of memory allocated from
> gcc-3.2.2\libstdc++-v3\libsupc++\eh_globals.cc, line 107 is not freed.
> 
> the code around that place
> g = (__cxa_eh_globals *) __gthread_getspecific (globals_key);
> if (! g)
> {
> if ((g = (__cxa_eh_globals *)
> std::malloc (sizeof (__cxa_eh_globals))) == 0  // **** <===  that is !!! 
> ***
> || __gthread_setspecific (globals_key, (void *) g) != 0)
> std::terminate ();
> g->caughtExceptions = 0;
> g->uncaughtExceptions = 0;
> }
> 
> My platform bsp is pc586, rtems ver is 4.6.0pre5. I can send the test I 
> used to detect the leak.
> What can I do now ?
> 
> Best regards,
> Valery
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gxx_wrappers.c.diff
URL: <http://lists.rtems.org/pipermail/users/attachments/20041014/12b34c3d/attachment-0001.ksh>