Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #549

Closed (moved)
Open
Opened Nov 11, 2007 by Roger Dingledine@arma

massive memory leak in exit nodes

mikeperry ran 0.1.2.17 on his exit node under valgrind:

==1715== 141,696 bytes in 492 blocks are possibly lost in loss record 15 of 17 ==1715== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==1715== by 0x80B7240: _tor_malloc (util.c:116) ==1715== by 0x80B8F06: _tor_malloc_zero (util.c:135) ==1715== by 0x808AB2A: dns_resolve (dns.c:719) ==1715== by 0x8071513: connection_exit_begin_conn (connection_edge.c:2250) ==1715== by 0x8095BA3: connection_edge_process_relay_cell (relay.c:1023) ==1715== by 0x8096310: circuit_receive_relay_cell (relay.c:171) ==1715== by 0x805B96E: command_process_cell (command.c:327) ==1715== by 0x80732BC: connection_or_process_inbuf (connection_or.c:768) ==1715== by 0x8067954: connection_process_inbuf (connection.c:2238) ==1715== by 0x806A792: connection_handle_read (connection.c:1449) ==1715== by 0x8091107: conn_read_callback (main.c:422) ==1715== ==1715== ==1715== 178,968,672 (177,808,896 direct, 1,159,776 indirect) bytes in 617,392 blocks are definitely lost in loss record 17 of 17 ==1715== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==1715== by 0x80B7240: _tor_malloc (util.c:116) ==1715== by 0x80B8F06: _tor_malloc_zero (util.c:135) ==1715== by 0x808AB2A: dns_resolve (dns.c:719) ==1715== by 0x8071513: connection_exit_begin_conn (connection_edge.c:2250) ==1715== by 0x8095BA3: connection_edge_process_relay_cell (relay.c:1023) ==1715== by 0x8096310: circuit_receive_relay_cell (relay.c:171) ==1715== by 0x805B96E: command_process_cell (command.c:327) ==1715== by 0x80732BC: connection_or_process_inbuf (connection_or.c:768) ==1715== by 0x8067954: connection_process_inbuf (connection.c:2238) ==1715== by 0x806A792: connection_handle_read (connection.c:1449) ==1715== by 0x8091107: conn_read_callback (main.c:422)

That's this malloc in dns.c: /* not there, need to add it */ resolve = tor_malloc_zero(sizeof(cached_resolve_t)); resolve->magic = CACHED_RESOLVE_MAGIC;

My first thought is that the "if" above that can still have resolve there, just without the expected 'expired' value. We should convert r12469 into an assert at some point.

On closer inspection, r12470 looks like a better candidate for the problem.

[Automatically added by flyspray2trac: Operating System: All]

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#549