Opened 7 years ago

Closed 7 years ago

#7022 closed defect (fixed)

memory leak in pathbias_count_first_hop()

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

found on moria5 running git master 64676d05714a8248) as a relay:

==28065== 1 bytes in 1 blocks are definitely lost in loss record 2 of 28
==28065==    at 0x4C244E8: malloc (vg_replace_malloc.c:236)
==28065==    by 0x5F59C61: strdup (strdup.c:43)
==28065==    by 0x211C1D: _tor_strdup (util.c:241)
==28065==    by 0x2123DB: rate_limit_log (util.c:1721)
==28065==    by 0x184E3E: circuit_finish_handshake (circuitbuild.c:2737)
==28065==    by 0x138D31: connection_edge_process_relay_cell (relay.c:1216)
==28065==    by 0x139A6B: circuit_receive_relay_cell (relay.c:203)
==28065==    by 0x19AA7D: command_process_cell (command.c:576)
==28065==    by 0x1BF716: connection_or_process_cells_from_inbuf (connection_or.c:1872)
==28065==    by 0x1B2623: connection_handle_read (connection.c:2723)
==28065==    by 0x11CA50: conn_read_callback (main.c:706)
==28065==    by 0x52C9343: event_base_loop (in /usr/lib/libevent-1.4.so.2.1.3)

Are there other cases where our 'rate limit' idiom breaks down and we don't free stuff?

Child Tickets

Change History (4)

comment:1 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-final

Every rate_limit_log in circuitbuild.c is suspect.

This leak exists in 0.2.3.

comment:2 Changed 7 years ago by nickm

None of the other rate_limit_log occurrences looked bad to me, though I might have made a mistake.

comment:3 Changed 7 years ago by arma

Status: newneeds_review

see my bug7022 branch (on maint-0.2.3)

comment:4 Changed 7 years ago by nickm

Keywords: tor-client added; tor-relay removed
Resolution: fixed
Status: needs_reviewclosed

Looks better; merging.

Note: See TracTickets for help on using tickets.