Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 313
    • Issues 313
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 34
    • Merge requests 34
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #549
Closed
Open
Created Nov 11, 2007 by Roger Dingledine@armaReporter

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
Time tracking