The memory leak in bug 2422 and storeUpdate

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
Received on Mon Aug 25 2008 - 10:51:57 MDT