# Memory leaks when used as a shared library

**URL:** <https://www.ruby-forum.com/t/memory-leaks-when-used-as-a-shared-library/242839>\
**Category:** NGINX\
**Created:** [August 1, 2015, 3:57am UTC](https://www.ruby-forum.com/t/memory-leaks-when-used-as-a-shared-library/242839 "2015-08-01T03:57:47Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sadaf\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/858c86/32.png) [@Sadaf\_N](https://www.ruby-forum.com/u/Sadaf_N)\
**Post date:** [August 1, 2015, 3:57am UTC](https://www.ruby-forum.com/t/memory-leaks-when-used-as-a-shared-library/242839/1 "2015-08-01T03:57:47Z")

</div>

Hi,

I want to build nginx into a shared library for this feature of  
nginx-clojure: [APIs for Embedding Nginx-Clojure into a Clojure/Java/Groovy App · Issue #86 · nginx-clojure/nginx-clojure · GitHub](https://github.com/nginx-clojure/nginx-clojure/issues/86)  
.  
But i found that there’s memory leaks after stop server but without exit  
the  
process. Then I tried valgrind to check a simple test without any 3rd  
party  
module.

$ nginx -V

nginx version: nginx/1.8.0  
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)  
configure arguments:   
$

test.conf  
=================start of test.conf==============================

daemon off;  
master\_process off;

error\_log logs/error.log;

events {  
worker\_connections 1024;  
}

http {

```
include mime.types;
default_type text/html;

access_log off;

sendfile on;

keepalive_timeout 65;

server {
   listen 8081;
   server_name localhost;

   location /hello {
      alias /nginx-clojure-embed/test/work-dir;
   }
}

```

}

=================end of test.conf==============================

The result of valgrind is here:

$ valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all  
–leak-check=yes objs/nginx -c work-dir/test.conf -p work-dir  
==10039== Memcheck, a memory error detector  
==10039== Copyright (C) 2002-2013, and GNU GPL’d, by Julian Seward et  
al.  
==10039== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for  
copyright  
info  
==10039== Command: objs/nginx -c work-dir/test.conf -p work-dir  
==10039==  
-==10039==  
==10039== HEAP SUMMARY:  
==10039== in use at exit: 441,239 bytes in 148 blocks  
==10039== total heap usage: 197 allocs, 49 frees, 613,884 bytes  
allocated  
==10039==  
==10039== 48 bytes in 1 blocks are still reachable in loss record 1 of  
10  
==10039== at 0x4C2ABFD: malloc (vg\_replace\_malloc.c:299)  
==10039== by 0x41CB98: ngx\_alloc (ngx\_alloc.c:22)  
==10039== by 0x403E9B: ngx\_save\_argv (nginx.c:817)  
==10039== by 0x40434D: main (nginx.c:316)  
==10039==  
==10039== 128 bytes in 1 blocks are possibly lost in loss record 2 of 10  
==10039== at 0x4C2ABFD: malloc (vg\_replace\_malloc.c:299)  
==10039== by 0x41CB98: ngx\_alloc (ngx\_alloc.c:22)  
==10039== by 0x40CAD2: ngx\_crc32\_table\_init (ngx\_crc32.c:117)  
==10039== by 0x40452C: main (nginx.c:332)  
==10039==  
==10039== 151 bytes in 5 blocks are still reachable in loss record 3 of  
10  
==10039== at 0x4C2ABFD: malloc (vg\_replace\_malloc.c:299)  
==10039== by 0x41CB98: ngx\_alloc (ngx\_alloc.c:22)  
==10039== by 0x403EE7: ngx\_save\_argv (nginx.c:825)  
==10039== by 0x40434D: main (nginx.c:316)  
==10039==  
==10039== 2,160 bytes in 1 blocks are still reachable in loss record 4  
of  
10  
==10039== at 0x4C2ABFD: malloc (vg\_replace\_malloc.c:299)  
==10039== by 0x41CACD: ngx\_strerror\_init (ngx\_errno.c:60)  
==10039== by 0x403F74: main (nginx.c:211)  
==10039==  
==10039== 3,030 bytes in 135 blocks are still reachable in loss record 5  
of  
10  
==10039== at 0x4C2ABFD: malloc (vg\_replace\_malloc.c:299)  
==10039== by 0x41CB0E: ngx\_strerror\_init (ngx\_errno.c:69)  
==10039== by 0x403F74: main (nginx.c:211)  
==10039==  
==10039== 3,594 bytes in 1 blocks are still reachable in loss record 6  
of  
10  
==10039== at 0x4C2ABFD: malloc (vg\_replace\_malloc.c:299)  
==10039== by 0x41CB98: ngx\_alloc (ngx\_alloc.c:22)  
==10039== by 0x41F260: ngx\_init\_setproctitle (ngx\_setproctitle.c:47)  
==10039== by 0x41F3E4: ngx\_os\_init (ngx\_posix\_init.c:43)  
==10039== by 0x4048F4: main (nginx.c:324)  
==10039==  
==10039== 6,144 bytes in 1 blocks are still reachable in loss record 7  
of  
10  
==10039== at 0x4C2ABFD: malloc (vg\_replace\_malloc.c:299)  
==10039== by 0x41CB98: ngx\_alloc (ngx\_alloc.c:22)  
==10039== by 0x421832: ngx\_epoll\_init (ngx\_epoll\_module.c:348)  
==10039== by 0x41A239: ngx\_event\_process\_init (ngx\_event.c:626)  
==10039== by 0x42132C: ngx\_single\_process\_cycle  
(ngx\_process\_cycle.c:298)  
==10039== by 0x4048A7: main (nginx.c:416)  
==10039==  
==10039== 106,496 bytes in 1 blocks are indirectly lost in loss record 8  
of  
10  
==10039== at 0x4C2ABFD: malloc (vg\_replace\_malloc.c:299)  
==10039== by 0x41CB98: ngx\_alloc (ngx\_alloc.c:22)  
==10039== by 0x41A424: ngx\_event\_process\_init (ngx\_event.c:689)  
==10039== by 0x42132C: ngx\_single\_process\_cycle  
(ngx\_process\_cycle.c:298)  
==10039== by 0x4048A7: main (nginx.c:416)  
==10039==  
==10039== 106,496 bytes in 1 blocks are indirectly lost in loss record 9  
of  
10  
==10039== at 0x4C2ABFD: malloc (vg\_replace\_malloc.c:299)  
==10039== by 0x41CB98: ngx\_alloc (ngx\_alloc.c:22)  
==10039== by 0x41A479: ngx\_event\_process\_init (ngx\_event.c:701)  
==10039== by 0x42132C: ngx\_single\_process\_cycle  
(ngx\_process\_cycle.c:298)  
==10039== by 0x4048A7: main (nginx.c:416)  
==10039==  
==10039== 425,984 (212,992 direct, 212,992 indirect) bytes in 1 blocks  
are  
definitely lost in loss record 10 of 10  
==10039== at 0x4C2ABFD: malloc (vg\_replace\_malloc.c:299)  
==10039== by 0x41CB98: ngx\_alloc (ngx\_alloc.c:22)  
==10039== by 0x41A3F5: ngx\_event\_process\_init (ngx\_event.c:682)  
==10039== by 0x42132C: ngx\_single\_process\_cycle  
(ngx\_process\_cycle.c:298)  
==10039== by 0x4048A7: main (nginx.c:416)  
==10039==  
==10039== LEAK SUMMARY:  
==10039== definitely lost: 212,992 bytes in 1 blocks  
==10039== indirectly lost: 212,992 bytes in 2 blocks  
==10039== possibly lost: 128 bytes in 1 blocks  
==10039== still reachable: 15,127 bytes in 144 blocks  
==10039== suppressed: 0 bytes in 0 blocks  
==10039==  
==10039== For counts of detected and suppressed errors, rerun with: -v  
==10039== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

There are a lot of memory leaks. e.g. ngx\_epoll\_done will never be  
called  
so event\_list has no chance to be freed.

Thanks.  
Xfeep

Posted at Nginx Forum:

> **[Memory leaks when used as a shared library](https://forum.nginx.org/read.php?2,260692,260692#msg-260692)**
>
> Hi, I want to build nginx into a shared library for this feature of nginx-clojure: https://github.com/nginx-clojure/nginx-clojure/issues/86 . But i found that there's memory leaks after stop server but without exit the process. Then I tried valgrind...

---

<div class="post-metadata">

**Author:** ![xfeep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/x/a4c791/32.png) [@xfeep](https://www.ruby-forum.com/u/xfeep)\
**Post date:** [August 1, 2015, 4:32am UTC](https://www.ruby-forum.com/t/memory-leaks-when-used-as-a-shared-library/242839/2 "2015-08-01T04:32:50Z")

</div>

BTW, after start nginx by valgrind it won’t print memory leaks report  
until  
we stop nginx by

$ objs/nginx -c work-dir/test.conf -p work-dir

Posted at Nginx Forum:

> **[Re: Memory leaks when used as a shared library](https://forum.nginx.org/read.php?2,260692,260693#msg-260693)**
>
> Hi, I want to build nginx into a shared library for this feature of nginx-clojure: https://github.com/nginx-clojure/nginx-clojure/issues/86 . But i found that there's memory leaks after stop server but without exit the process. Then I tried valgrind...

---

<div class="post-metadata">

**Author:** ![xfeep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/x/a4c791/32.png) [@xfeep](https://www.ruby-forum.com/u/xfeep)\
**Post date:** [August 2, 2015, 4:56am UTC](https://www.ruby-forum.com/t/memory-leaks-when-used-as-a-shared-library/242839/3 "2015-08-02T04:56:15Z")

</div>

Hello!

On Fri, Jul 31, 2015 at 09:57:05PM -0400, xfeep wrote:

> I want to build nginx into a shared library for this feature of  
> nginx-clojure: [APIs for Embedding Nginx-Clojure into a Clojure/Java/Groovy App · Issue #86 · nginx-clojure/nginx-clojure · GitHub](https://github.com/nginx-clojure/nginx-clojure/issues/86) .  
> But i found that there’s memory leaks after stop server but without exit the  
> process. Then I tried valgrind to check a simple test without any 3rd party  
> module.

Well, the answer is simple: nginx is not designed to be a shared  
library. If you want to convert it to be one, it’s you who are  
responsible for cleaning up various global allocations.

–  
Maxim D.

> **[nginx](http://nginx.org/)**

---

<div class="post-metadata">

**Author:** ![xfeep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/x/a4c791/32.png) [@xfeep](https://www.ruby-forum.com/u/xfeep)\
**Post date:** [August 2, 2015, 4:32pm UTC](https://www.ruby-forum.com/t/memory-leaks-when-used-as-a-shared-library/242839/4 "2015-08-02T16:32:02Z")

</div>

Hi, Maxim,

## Thanks for your reply!

> Well, the answer is simple: nginx is not designed to be a shared  
> library. If you want to convert it to be one, it’s you who are  
> responsible for cleaning up various global allocations.

You’re right.  
But for module developers who use valgrind there are maybe some  
confusion,  
the built-in core modules also have “memory leaks” , despite the fact  
that  
those are not real leaks because OS will free them after nginx  
master/worker processes exit.

Regards.  
Xfeep

Posted at Nginx Forum:  
[http://forum.nginx.org/read.php?2,260692,260704#msg-260704](http://forum.nginx.org/read.php?2,260692,260704#msg-260704)

---

<div class="post-metadata">

**Author:** ![xfeep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/x/a4c791/32.png) [@xfeep](https://www.ruby-forum.com/u/xfeep)\
**Post date:** [August 5, 2015, 1:51am UTC](https://www.ruby-forum.com/t/memory-leaks-when-used-as-a-shared-library/242839/5 "2015-08-05T01:51:15Z")

</div>

Hi, Lord,  
Thank you!

## Lord N. Wrote:

> Have you looked at [GitHub - openresty/no-pool-nginx: replace nginx's pool mechanism with plain malloc & free to help tools like valgrind · GitHub](https://github.com/openresty/no-pool-nginx) ?

But the issue in my case is not related to nginx’s pool mechanism.  
It is caused by some build-in modules which won’t release it allocated  
memory at all. e.g.  
ngx\_event\_core\_module.init\_process does some allocating but there 's no  
ngx\_event\_core\_module.exit\_process at all, so the memory it allocated  
will  
only be released by operation system process manager only when the  
worker  
process exits. it is plain that this will be reported as memory leak by  
valgrind.

Just as Maxim said, I plan to write a new process\_cycle for my shared  
library and record all unreleased memory and do release them at the end  
of  
process\_cycle.

Regards.  
Xfeep

Posted at Nginx Forum:  
[http://forum.nginx.org/read.php?2,260692,260765#msg-260765](http://forum.nginx.org/read.php?2,260692,260765#msg-260765)

---

<div class="post-metadata">

**Author:** ![xfeep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/x/a4c791/32.png) [@xfeep](https://www.ruby-forum.com/u/xfeep)\
**Post date:** [August 4, 2015, 9:35pm UTC](https://www.ruby-forum.com/t/memory-leaks-when-used-as-a-shared-library/242839/6 "2015-08-04T21:35:58Z")

</div>

Have you looked at [GitHub - openresty/no-pool-nginx: replace nginx's pool mechanism with plain malloc & free to help tools like valgrind](https://github.com/openresty/no-pool-nginx) ?