About memory fragmentation and MallocNextGen

[blackwater]

Dennis, thanks for your response.

I have already used info heap filename and then compared the reports and found a memory leak. I think formally speaking iIt's not a memory leak, but anyway, the result was as if I had a memoty leak.

The problem was with a global list variable and a global boolean flag. They were defined and used in this way:

std::list global_list_variable;
bool global_list_variable_initialized = false;

void f()
{
if(!global_list_variable_initialized) {
global_list_variable.push_back(MyClass());
// global_list_variable_initialized
// by mistake was not set to true
}
}

As for your suggestion "It appears you need to increase your thread stack size.". What do you mean? My application doesn't cause this error when it runs. It only happens when I run info leaks under gdb. So where should I increase thread stack size and how? Do you mean setting maxssiz_64bit? Could you explain, please?

[Dennis Handly]

>The problem was with a global list variable and a global boolean flag.

Why have two data structures to track one thing? Just use:
if (global_list_variable.begin() == global_list_variable.end()) {
global_list_variable.push_back(MyClass())

(Unless f() is called after there are entries on the list.)

My application doesn't cause this error when it runs. It only happens when I run info leaks under gdb.

Right. IF you want to use gdb, you would need to increase your thread stacksize.

>So where should I increase thread stack size and how?

When you do pthread_create, you need to set the thread stacksize attribute with:
pthread_attr_setstacksize(3)

Or export PTHREAD_DEFAULT_STACK_SIZE with a larger size, in bytes.

[blackwater]

Dennis, thanks for your answer.

I made a search and found in one of libraries that I use a call to pthread_attr_setstacksize. I think I will comment it and recompile my application in order to experiment with PTHREAD_DEFAULT_STACK_SIZE. If I still have a problem with info leaks causing a coredump I will start another thread later.

[blackwater]

1) there is 64-bit MallocNextGen library

2) Seems like there is no need to set any enviroment variable in order to use it and existing enviroment variable like _M_SBA_OPTS doen't affect it.

3) The detailed memory report is generated
if I run a command "info heap filename"

4) "info heap" provides lots of information in order to find memory leaks and situations which look like a memory leak.

5) In order to run "info leak" for my application I need to increase thread stack size but I can't do it right now just by setting PTHREAD_DEFAULT_STACK_SIZE because in one of my library there is a call to pthread_attr_setstacksize(). I need to comment the call and recompile the application in order to see if "info leaks" does not result in a coredump.

[blackwater]

One more point.

The detailed report showed that the majority of memory blocks are less than 1024 bytes and there are few which are quite big.
So it is appropriate to set
_M_SBA_OPTS=1024:100:16

Seems like after assigning _M_SBA_OPTS this value I can expect that there might be no memory fragmentation.

[Jini Susan George]

Hi,

Here it looks like your main thread has exited when 'info leaks' fails with stack overflow. Could you please check if this is the case? If so, could you check if the main thread can be retained till whenever you need to issue the command to detect leaks?

- Jini.

[blackwater]

One more point. I have made a version of the program that didn't use pthread_attr_setstacksize(). Then I created a shell script that exported PTHREAD_DEFAULT_STACK_SIZE and ran the program under gdb. I tried setting PTHREAD_DEFAULT_STACK_SIZE with a very big number and with not so big number. In both cases when I used "info leaks" I got the same error (a signal and then a coredump).

At this point I decided to change the way I test the program. Instead of loading all the records from a database I changed a configuration of the program and started loading only records which were necessary for running my tests. That resulted in a significant decrease in number of memory allocations. And as a result of it executing "info leaks" didn't result in a coredump.