idnsGrokReply leaks

Hello,

     Requesting http://www.google.com/ results in the following leak:

> 4 bytes in 1 blocks are definitely lost in loss record 14 of 950
> at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
> by 0x684C6F: xmalloc (in /home/rousskov/Edit/squid3/trunk/src/squid)
> by 0x6820B9: rfc1035RRUnpack (in /home/rousskov/Edit/squid3/trunk/src/squid)
> by 0x6826E3: rfc1035MessageUnpack (in /home/rousskov/Edit/squid3/trunk/src/sq
> by 0x50BC0D: idnsGrokReply(char const*, unsigned long) (dns_internal.cc:962)
> by 0x50ECB0: idnsRead(int, void*) (dns_internal.cc:1207)
> by 0x4F7531: comm_select (comm_epoll.cc:307)
> by 0x604970: CommSelectEngine::checkEvents(int) (comm.cc:2463)
> by 0x514534: EventLoop::checkEngine(AsyncEngine*, bool) (EventLoop.cc:50)
> by 0x514735: EventLoop::runOnce() (EventLoop.cc:124)
> by 0x514845: EventLoop::run() (EventLoop.cc:94)
> by 0x56E1A4: SquidMain(int, char**) (main.cc:1477)
> by 0x56E2CF: SquidMainSafe(int, char**) (main.cc:1207)
> by 0x56E3B8: main (main.cc:1199)

I fixed the above leak (trunk r10841). Please check and port.

Unfortunately, idnsGrokReply() is probably sill leaky because it
incorrectly assumes that a successful call to rfc1035MessageUnpack()
returns the number of allocated answers. rfc1035MessageUnpack() actually
returns something like the number of first successfully parsed answers.

If you have a chance, please fix the A/AAAA merging code to avoid
leaking invalid RRs and check the rest of the idnsGrokReply() code for
similar bugs.

Perhaps rfc1035 code should be changed to free unparsed RRs proactively
when the result is positive? This would avoid the difference between the
return result and the number of RRs we should care about.

Thank you,

Alex.
Received on Fri Sep 10 2010 - 22:20:25 MDT