Re: [rvm-research] Memory Leaks in Thread Creation/Deletion

        STATEMENT OF ORIGIN FOR A SINGLE CONTRIBUTOR

I, Carl Ritson:

(a) represent that either:

  (i) I am the only author and owner of the contributed software
      (described as/entitled Fixes for Memory Leaks in sys.C),
      which was neither derived nor copied from any other software,
  or

 (ii) that any exception to (i) is software which was obtained under the
      EPL (Eclipse Public License),

and

(b)  hereby agree to license this contributed software under the EPL.


2014-09-08 11:44 GMT+01:00 Erik Brangs <[email protected]>:
> Hi,
>
> On 05.09.2014 16:18, Carl Ritson wrote:
>> For debugging I recently wrote a test that endless creates and
>> terminates threads (attached as ThreadTest3.java).  This test
>> consistently crashes JikesRVM after about 450,000 threads have been
>> created.  The crash occurs when pthread_create fails due to a lack of
>> resources, or as it turns out, a lack of memory.
> I can reproduce the crash on hg tip.
>
>> Digging around in sys.C it seems some allocation is done with C++
>> primitives (new/delete) and the rest with malloc/free.  There doesn't
>> appear to be an obvious reason for this.
>> There also seem to be two distinct memory leaks:
>>  1. the memory allocated for the parameters passed to the new thread
>> via pthread_create is not freed.
>>  2. the signal handling stack can be allocated twice, once by
>> sysThreadStartup and once by sysSetupHardwareTrapHandler; however,
>> only the stack allocated by sysThreadStartup will be release when a
>> thread terminates.
>>
>> Attached is a patch which attempts to address these issues with
>> (mostly) minimal changes:
>>  A. uses of new/delete are replaced with malloc/free.
>>  B. all calls to malloc/free pass via (existing) checking functions to
>> check for address space overlaps.
>>  C. thread parameters are releases at thread termination.
>>  D. thread termination checks for the presence of an alternate signal
>> stack and release it if present.
> The patch looks ok to me at first glance. If you're satisfied with your changes, I could commit them once you provide a contributor statement.
>
>
> Kind regards,
>
> Erik Brangs
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk