Ive been chatting with Chris about this and it turns out turning off store update plugged the memory leak in 2.7.STABLEx.
The main "leak" from a valgrind trace is thus: ==00:00:09:27.008 7355== 1,308,371 (1,210,456 direct, 97,915 indirect) bytes in 802 blocks are definitely lost in loss record 36 of 38 ==00:00:09:27.008 7355== at 0x4A1AD7D: calloc (vg_replace_malloc.c:279) ==00:00:09:27.008 7355== by 0x4B7593: xcalloc (util.c:561) ==00:00:09:27.008 7355== by 0x46B1FC: memPoolAlloc (MemPool.c:303) ==00:00:09:27.008 7355== by 0x422554: cbdataInternalAlloc (cbdata.c:212) ==00:00:09:27.008 7355== by 0x455FA3: httpStart (http.c:1485) ==00:00:09:27.008 7355== by 0x4426D1: fwdDispatch (forward.c:757) ==00:00:09:27.008 7355== by 0x44164F: fwdConnectDone (forward.c:361) ==00:00:09:27.008 7355== by 0x432BA3: commConnectCallback (comm.c:366) ==00:00:09:27.008 7355== by 0x4330F9: commConnectHandle (comm.c:486) ==00:00:09:27.008 7355== by 0x435954: comm_call_handlers (comm_generic.c:300) ==00:00:09:27.008 7355== by 0x436145: do_comm_select (comm_epoll.c:193) ==00:00:09:27.008 7355== by 0x435C4D: comm_select (comm_generic.c:390) Henrik, what could possibly cause a httpState leak in the store update code? I'm worried about this because its currently a "default-on" option in 2.HEAD and 2.7 and its leaking memory. I don't like this for obvious reasons.. Adrian
