Bugzilla – Bug 4605
Possible memory leak in Globus RSL pre-WS
Last modified: 2007-02-14 14:51:24
You need to
before you can comment on or make changes to this bug.
We have some code which uses globus rsl pre-ws code, which leaks memory.
There is no gram network invovled. I've attached a small c code snippet which
reproduces the problem.
Valgrind stack trace of the leak.
==15646== 16384 bytes in 2 blocks are still reachable in loss record 447 of 487
==15646== at 0x3414C59D: malloc (vg_replace_malloc.c:130)
==15646== by 0x34860844: globus_libc_malloc (globus_libc.c:418)
==15646== by 0x348633FD: globus_l_memory_create_list (globus_memory.c:123)
==15646== by 0x348635A1: globus_memory_pop_node (globus_memory.c:180)
==15646== by 0x34862EFC: globus_list_insert (globus_list.c:353)
==15646== by 0x346FF6C0: globus_list_copy_reverse (globus_rsl.c:766)
==15646== by 0x346FEE15: globus_rsl_copy_recursive (globus_rsl.c:391)
==15646== by 0x34198727: XrslRelation::XrslRelation(_globus_rsl_t*)
==15646== by 0x3419ABC6: Xrsl::GetRelation(std::string const&)
==15646== by 0x341F97AB: Target::GetCputime(Xrsl) (stl_alloc.h:652)
==15646== by 0x341F48B9: CpuTimeBroker::RelationCheck(Target&,
Created an attachment (id=1004) [details]
Small C file which reproduces the problem.
Btw. the stack trace is from Globus 2.4.
Since Stu and Joe are on vacation, I'm assigning this to Martin.
Almost forgot. The problem has been verified on 2.4 and 4.1.0
(In reply to comment #5)
> Almost forgot. The problem has been verified on 2.4 and 4.1.0
Okay I need to read what I write: 2.4 and 4.0.2 has the problem. 4.1.0 is
I'm interested in hearing about this bug as well, so I'll add myself as cc, if
There is a globus RSL memleak patch in circulation. I tried it, but it does not
appear to fix my problems. I'm attaching it.
Created an attachment (id=1005) [details]
Circulating RSL memleak patch
This is a patch for fixing a memory leak in globus rsl. It might fix a memory
leak, but the problem stille occured when using it.
I just tried the attached example with valgrind and it
seems that the globus_list is affected too.
But I'm new to this library, so let me have a look :-)
Created an attachment (id=1006) [details]
fixes a memory leak
Seems like I found the error.
At least I can run the example attached in "Small C file which reproduces
the problem" without memory leaks now.
There are memory leaks in globus_rsl.c. That's the file where all functions
that work on an rsl type are defined.
The problem are the calls to the function globus_list_copy_reverse(...)
which is defined in globus_rsl.c too and which creates a reverse copy of a
The calls in globus_rsl.c (there are three calls) look like this:
list = globus_list_copy_reverse(list);
This code works, but the problem with this is that the pointer to the new
list created by globus_list_copy_reverse(...) is stored in same pointer like
the list that is given as argument. This means that the pointer to the old
list is overwritten and thus the old list is not referenced anymore and lost
I don't know if there are differences between our GT versions. That's why
I attached my new globus_rsl.c (source-trees/gram/rsl/source/globus_rsl.c)
as a "manual patch". You can find the changes when you search for
I simply stored the new, reversed list in a new variable and free'd the
An alternative to this would be to add a new function to globus_list which
adds an element at the end of the list. With this there would be no need
to call globus_list_copy_reverse(...).
Change these things in the code, try it out and please tell me about
I extended the above example C-file by freeing the rsl at the end of the
The output of valgrind (valgrind-3.2.0) of the command
valgrind --tool=memcheck --leak-check=yes memLeakTest
was the following:
==16320== Memcheck, a memory error detector for x86-linux.
==16320== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==16320== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==16320== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==16320== For more details, rerun with: -v
==16320== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1)
==16320== malloc/free: in use at exit: 16426 bytes in 2 blocks.
==16320== malloc/free: 10126 allocs, 10124 frees, 135104 bytes allocated.
==16320== For counts of detected errors, rerun with: -v
==16320== searching for pointers to 2 not-freed blocks.
==16320== checked 1664660 bytes.
==16320== LEAK SUMMARY:
==16320== definitely lost: 0 bytes in 0 blocks.
==16320== possibly lost: 0 bytes in 0 blocks.
==16320== still reachable: 16426 bytes in 2 blocks.
==16320== suppressed: 0 bytes in 0 blocks.
==16320== Reachable blocks (those to which a pointer was found) are not shown.
==16320== To see them, rerun with: --show-reachable=yes
I wondered about the "still reachable: 16426 bytes in 2 blocks."
The explanation is probably:
A Parser generated by Flex and Bison is used to create the rsl from the
string in the function call
rsl = globus_rsl_parse(job);
I created a very simple dummy scanner using flex without using any globus
code, started this program with valgrind too and the result was the same:
"still reachable: 16426 bytes in 2 blocks."
So I'm quite sure that the reason for this message can be found in flex.
Here is a discussion on flex and possible memory leaks:
sorry, i forgot to say that I work with GT version 4.0.2.
My attachment "fixes a memory leak" is the modified file globus_rsl.c
from this GT version
This appears to fix memory leak. Excellent! Thanks for fixing this so quickly.
I've produced a patch for 4.0.2 (cleaned up some whitespace/tab noise from the
fixed file). I'll attach it. I assume this will go into the dev tree.
Will there be an updated package to globus 4.0.2? It is not important for us as
we are aware of the problem and can now deal with it, but it has been a
showstopper for some, and it might be for others.
Created an attachment (id=1012) [details]
Patch for Globus 4.0.2 which fixes the memory leak
Based on Martins globus_rsl.c file. Cleaned up tab noise.
hm, i never imported something to CVS and don't have the rights to do so,
because i'm a newbie in the Globus team.
I'll ask some people how to deal with this ...
Can you review test and commit this patch? I think it should be committed to
4.0 branch and trunk.
Martin: nice job on the fix!
Looks good. I committed to 4.0 branch and trunk.