Is it a mallocNG related question?

[blackwater]

Two backtraces is in the attached file.

[blackwater]

Forget to mention. Both processes generated a core file.

This is a message for the second backtrace:

Core was generated by `rating_server'.
Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped to object

[blackwater]

Seems like
export PTHREAD_DEFAULT_STACK_SIZE=1000000
fixed the problem.

[Dennis Handly]

That's the first place I would start.
Also, do you have a thread stack overflow? You may need to allocate more stack space when using mallocNG.

It could be heap corruption where you have recursion when you shouldn't?

[blackwater]

Dennis,

Could you explain whether or not I have to change maxssiz_64bit?

I mean that I have set "export PTHREAD_DEFAULT_STACK_SIZE=1000000" and in this situation should I somehow change value of maxssiz_64bit? I don't actually understand if there is any link between these two variables (maxssiz_64bit & PTHREAD_DEFAULT_STACK_SIZE).

For example I have a process that is going to have around 100 threads. OK, I am going to set PTHREAD_DEFAULT_STACK_SIZE=1Mb. Then each thread will have around 500Kb of stack. Is it necessary to have maxssiz_64bit equal ot more than 500Kb * 100 which is 50 Mb?

[Dennis Handly · Accepted solution]

>Could you explain whether or not I have to change maxssiz_64bit?

No. This only controls the main thread, not any you create.

>each thread will have around 500Kb of stack.

Actually .5 Mb user stack and .5 Mb RSE stack.

>Is it necessary to have maxssiz_64bit equal to more than 50 Mb?

No, no connection. (And maxssiz_64bit is probably already larger than that. :-)

[blackwater]

Dennis,

I have one more question after reading this http://h20338.www2.hp.com/enterprise/w1/en/os/hpux11i-v3-next-generation-memory-allocator.html.

So I have relinked the application and now it depends on mallocNG. We run the application from a shell script that looks like this:

#/bin/sh
export LD_PRELOAD=one-small-snmp-library.so
my_application


one-small-snmp-library.so doesn't use mallocNG. It uses malloc() from libc. As far as I understand LD_PRELOAD tells the OS to load one-small-snmp-library.so and all libraries that it uses before my application. As a result malloc() from libc has to be loaded. Still my application seems to use malloc() from mallocNG cause it consumes less memory.

I don't care how much memory one-small-snmp-library.so consumes since it is not a lot. But I would like to find out if my application will always use malloc() from mallocNG whatever libraries are preloaded with LD_PRELOAD? Or is it necessary to add export LD_PRELOAD=mallocng.so:memory one-small-snmp-library.so?

In other words is dependency on malloc() in my application will always bring malloc() from mallocNG?

[Dennis Handly]

>one-small-snmp-library.so doesn't use mallocNG. It uses malloc() from libc.

Why do you say that? You have mallocNG.

>LD_PRELOAD tells the OS to load one-small-snmp-library.so and all libraries that it uses

Hmm. What does chatr(1) show for one-small-snmp-library.so? It better not be linked with libc.

>In other words is dependency on malloc() in my application will always bring malloc() from mallocNG?

It should, otherwise mallocNG isn't that useful a replacement for malloc. And you would get all sorts of aborts.

I suppose it depends on whether mallocNG uses interposition and dld to activate itself or some other trick.

[blackwater]

1. mallocNG requires more stack space. Seems like "export PTHREAD_DEFAULT_STACK_SIZE=1000000" is a proper answer to the first question. Or using pthread_attr_setstacksize() before starting a POSIX thread is even better.

2. It is not necessary to change maxssiz_64bit when I set "export PTHREAD_DEFAULT_STACK_SIZE=1000000".

[blackwater]

>>In other words is dependency on malloc() in my application will always bring malloc() from mallocNG?

>It should, otherwise mallocNG isn't that useful a replacement for malloc.

Seems like I found an explanation in HP documentation. http://www.docs.hp.com/en/14640/OnlineHelp/linkerdifferencesiapa.htm#dynamicpathsearchin, Section "Symbol Searching in Dependent Libraries".

In my example mallocNG is a shared library of the first level (since the application has been built with -lmallocng) and when malloc() is called the dynamic link loader must find it using breadth-first search in libmalloc and not in the libc (since neither my application nor small-snmp-library were built with -lc so libc is not a shared library of the first level).

By the way, Dennis. I think there is a small typo in the documentation on this page:


$ ld -b lib2.o -o lib2.s
$ ld -b lib3.o -o lib3.s
$ d -b lib1.o -L. -l3 -o lib1.s
^^^^^^^
$ cc main.o -Wl,-L. -l1 -l2 -o main

I think must be
$ ld -b lib2.o -o lib2.s
$ ld -b lib3.o -o lib3.s
$ ld -b lib1.o -L. -l3 -o lib1.s
$ cc main.o -Wl,-L. -l1 -l2 -o main