FWD, this may be interesting to a larger audience.
Begin forwarded message:
> From: Heming Cui <heming at cs.columbia.edu>
> Date: April 1, 2010 5:23:55 PM GMT+02:00
> To: Cristian Zamfir <cristian.zamfir at epfl.ch>
> Cc: <daniel at zuster.org>, <c.cadar at imperial.ac.uk>, Junfeng Yang
> <junfeng at cs.columbia.edu>
> Subject: Re: [klee-dev] A question about the memory usage of local variable
> of functions in klee (for llvm-2.6)
>
> Hi Cristian,
> Thanks so much for your reply. I have checked the code, two concerns are:
> First, do we need to delete the memory in the unbind() function after it
> is removed from the "objects"? I have checked that, if we do not "delete"
> here, then there are just MemoryObject construction functions called (for
> each function call to foo()) but no destruction functions are called.
>
> void AddressSpace::unbindObject(const MemoryObject *mo) {
> objects = objects.remove(mo);
> delete mo; // I added this line.
> }
>
> Second, do we need to free the "address" memory for the memory object in
> its destruction function? I have checked that even we delete the memory
> object explictly in the unbind() function as above, but we do not free() this
> "address", the memory usage problem still occur.
>
> MemoryObject::~MemoryObject() {
> if (address) free((void *)address); // I added this line.
> address = 0; // I added this line.
> }
>
>
> I have added these two places, and it seems that now the memory usage is
> restricted to about 2%. Do we have other approaches to solve the memory usage
> problem? Am I missing something?
> I am looking forward to your reply.
>
> 2010/4/1 Cristian Zamfir <cristian.zamfir at epfl.ch>
>
> Hi Heming,
>
> If you run the example with just the return and without local vars, you
> should check in the assembly.ll to see if the call is not removed.
>
> Local variables are removed on function return, check ExecutionState.cpp:112
> You can maybe check the # of bytes removed, there could be a bug.
>
> Cristi
>
> On Apr 1, 2010, at 5:33 AM, Heming Cui wrote:
>
> > Dear Daniel and Cristian,
> > One more thing is, if I do not declare any local var at foo() and just
> > return (as below), the memory usage is only about 1%.
> > void foo() {
> > return;
> > }
> >
> >
> > 2010/3/31 Heming Cui <heming at cs.columbia.edu>
> > Dear Daniel and Cristian,
> > I am Heming Cui, Prof. Junfeng Yang's student. May I ask you a
> > question, please? Recently I was running klee with some long running
> > programs and found a question about the memory usage of local variable of
> > functions in klee.
> > Please refer to the source code below (and also in the attachment).
> > Foo() dedclares a function local var, and the main function calls fool()
> > again and again. If I compile this code with llvm-gcc and run the bit code
> > with klee, the memory usage increases to more than 90% as soon as the
> > program starts and never drops. The memory in my machine is 2GB. If I
> > compile this code with gcc and run it natively, and the memory usage is
> > only 0.1% and never increases.
> > If I change "int a[100000];" to be "int a;", the memory usage would
> > increase to more than 90% after about 10 seconds of start, and never drops.
> > It seems to me that we might need to unbind local vars in klee memory
> > address space after a function exits? I am a little confused of this part,
> > since if my program runs for a long time, this problem would happen and
> > affect the speed.
> >
> > Memory usage of klee is 93.3%:
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 3099 heming 20 0 1773m 469m 4 D 1.7 93.3 0:04.18 klee
> >
> >
> > Source code (also attached):
> >
> > #include <stdio.h>
> > void foo() {
> > int a[100000];
> > return;
> > }
> >
> > int main(int argc, char * argv[]) {
> > while (1) {
> > foo();
> > }
> >
> > return 0;
> > }
> >
> > --
> > Regards,
> > Heming Cui
> >
> >
> >
> >
> > --
> > Regards,
> > Heming Cui
> > _______________________________________________
> > klee-dev mailing list
> > klee-dev at keeda.stanford.edu
> > http://keeda.Stanford.EDU/mailman/listinfo/klee-dev
>
>
>
>
>
> --
> Regards,
> Heming Cui
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://keeda.Stanford.EDU/pipermail/klee-dev/attachments/20100401/786c5878/attachment-0001.html