Kevin Kreiser

we've seen this so many times on so many different compilers. at this point im wondering what is the right thing to do? it seems to me that some versions...

@noerw can you drop the output of `config.log` here?

@noerw thanks! the output looks the same as mine with respect to `DEPS_LIBS`... so can you then do: VERBOSE=1 make prime_serverd and share that output?

hmm... i was expecting that this part: ``` CXX src/libprime_server_la-zmq_helpers.lo CXX src/libprime_server_la-netstring_protocol.lo CXX src/libprime_server_la-http_util.lo CXX src/libprime_server_la-http_protocol.lo CXXLD libprime_server.la CXXLD prime_serverd ``` would actually show the compiler/linker command line and args......

so this is your link line: > libtool: link: g++ -I/home/norwin/src/prime_server/prime_server -g -O2 -o .libs/prime_serverd src/prime_serverd-prime_serverd.o ./.libs/libprime_server.so -lczmq -lzmq -lcurl and this is mine: > libtool: link: g++ -I/sandbox/prime_server/prime_server -g...

ok so let me reiterate what you've got here so i make sure i understand correctly. you've initialized the `graph` and `rstar_index` outside of your workers, you then only free...

I would guess that this library caches that information on purpose (ie its not a leak) so as to accelerate subsequent requests. indeed, [valhalla](https://github.com/valhalla/valhalla), the routing software that i use...

the `cleanup` method is called after every request. if you properly deallocate the things you are interested in deallocating in that function, your thread will not consume memory without bound....

now that is something i can look into, ill have a quick go with valgrind!

interesting, ive confirmed that `prime_serverd` is increasing in memory over the course of its life. ill look closer at it this weekend if i get a chance. thanks for pointing...