Can I use this to free up leaked memory

[jeffrycopps]

Memleax helps finding leaked memory.
Will it be possible to free up the leaked memory if I invoke this tool from the target process probably in a different thread?
I may sound lame, please correct me.
Thanks.

[WuBingzheng]

Sound interesting.

However you'd better not to invoke memleax from the target process.

If you could modify your program, I think it's better to make a new thread to receive request(from file or socket) to free memory with requested address, which are found by memleax outside.

Another way is that, memleax is still invoked independently and free the leaked memory when found. This is hard work to modify memleax but possible.

However, I think the best way is using memleax to find memory leak, and then YOU fix the bug! Is there any reason that you could not fix the bug?

[jeffrycopps]

Thanks for the quick reply.
I intended to say, invoke memleax not as a new process but a thread making it as a .DLL or .so.
Why? Because, OS doesn't allow us to have write access to a memory that is allocated by a different process is my belief.

I wanna use this on a process that invokes more than 200threads loading n number of libraries.
Firstly, its less probable to goto every possible codepoint during a single process execution.
Different people use the process for using different feature.
Lot of them report that memory utilization keeps getting high, if we could give a patch that would automatically delete leaked memory in real time in production environment. That would be great.

[WuBingzheng]

1. Actually a process CAN access the memory of other processes. This is also the reason why memleax can find the memory leak of other processes. It's all because of ptrace. Although "free memory" is much harder than "find memory leak".

2. I still think it is not good to free memory by memleax as a thread, especially in production environment. First memleax affects performance. Secondly, memleax just try to guess memory leak. If one of your threads really want to allocate a memory and never free it or free it in long time, it is not memory leak. If this is freed, it will bring Segment fault.

3. There are other ways to debug memory leak. One way is to recompile your program with new dynamic memory allocation libraries which record all memory allocation and free, such as Electric Fence. This way is much more suitable for your need. Because it affects much less performance, and can actively free memory very easily.
   The advantage of memleax over them is that, it need not to restart the target process or re-compile the target program. Since you can modify and re-compile your program, memleax is not the best choice.

Sorry for my poor English. Reply me if any confuse.

[jeffrycopps]

I agree your point, a process can access the memory of another process. But can it free memory which was allocated? Virtual memory concept will disallow to actually delete a memory of process 1 from process 2. Or correct me, if this is even possible.
Any memory leak detector does only guessing, we could assume memory leak is right if the leak probability reaches 100%.
"There are other ways to debug memory leak"- are there ways to free memory of a running process by introducing a new thread or from a different process?
I wanna use this tool on prod environment, where I cannot do a restart.
Can you tell me if there is a possibility to tweak in memleax to make it do the free part for leaks having 100% probability?

[WuBingzheng]

I think a process (usually a debugger) can infect into another process by ptrace, including accessing memory, modifying memory, calling function. You may see what GDB does.

I think the best way is that, you write a library which implements standard memory allocation functions(malloc calloc realloc free), and link your program with this library. In this library, you can guess memory leak and free the memory and need not to run a new thread to free memory. It may look like this:

void * malloc(size_t size) {
  void *p = __libc_malloc(size);
  record_memory_block(p, size);  // record the memory block
  free_leaked_memory();  // guest memory leak from the recorded memory blocks, and free them
  return p;
}
void free(void *p) {
  __libc_free(p);
}

As far as I know, all memory debuggers try to only find memory leak, but not free them. As you said, all debuggers can not make sure the memory leak. They all just guess.

I donot understand your last question.