View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001700 | GNUnet | transport service | public | 2011-06-16 11:43 | 2011-06-28 14:34 |
| Reporter | mrwiggles | Assigned To | Matthias Wachs | ||
| Priority | urgent | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Summary | 0001700: Memory leak in gnunet-service-transport (or plugins?) | ||||
| Description | gnunet-service-transport takes up around 300M of memory (running on planetlab nodes for with approximately 300 peers). Jun 16 09:42:05 transport-25599 WARNING External protocol violation detected at plugin_transport_tcp.c:2032 | ||||
| Additional Information | Fixed memory leaks... if more leaks exist please open a new bug report | ||||
| Tags | No tags attached. | ||||
| duplicate of | 0001719 | closed | Christian Grothoff | Core/transport api memory leak |
|
|
This appears to be the issue. ==4311== 12,250 bytes in 28 blocks are definitely lost in loss record 14 of 14 ==4311== at 0x43DD525: malloc (vg_replace_malloc.c:149) ==4311== by 0x4402C1F: GNUNET_xmalloc_unchecked_ (common_allocation.c:132) ==4311== by 0x4402A19: GNUNET_xmalloc_ (common_allocation.c:61) ==4311== by 0x804C1D9: transmit_to_peer (gnunet-service-transport.c:2212) ==4311== by 0x80511E6: transmit_hello_and_ping (gnunet-service-transport.c:4495) ==4311== by 0x804ECAE: setup_peer_check_blacklist (gnunet-service-transport.c:3632) ==4311== by 0x80516B4: run_validation (gnunet-service-transport.c:4632) ==4311== by 0x43E6460: delta_match (hello.c:419) ==4311== by 0x43E5F97: GNUNET_HELLO_iterate_addresses (hello.c:248) ==4311== by 0x43E64C7: GNUNET_HELLO_iterate_new_addresses (hello.c:451) ==4311== by 0x8051B3B: check_hello_validated (gnunet-service-transport.c:4761) ==4311== by 0x43E9A8C: peerinfo_handler (peerinfo_api.c:527) |
|
|
Two leaks... ==32258== 2,082 bytes in 5 blocks are possibly lost in loss record 15 of 18 ==32258== at 0x4022525: malloc (vg_replace_malloc.c:149) ==32258== by 0x403D60C: GNUNET_xmalloc_unchecked_ (common_allocation.c:132) ==32258== by 0x403D6B9: GNUNET_xmalloc_ (common_allocation.c:61) ==32258== by 0x804C40E: transmit_to_peer (gnunet-service-transport.c:2212) ==32258== by 0x804CB3F: setup_new_neighbour (gnunet-service-transport.c:3424) ==32258== by 0x804CDA4: handle_request_connect (gnunet-service-transport.c:5810) ==32258== by 0x405B630: GNUNET_SERVER_inject (server.c:688) ==32258== by 0x405B786: client_message_tokenizer_callback (server.c:902) ==32258== by 0x405C527: GNUNET_SERVER_mst_receive (server_mst.c:229) ==32258== by 0x405B085: process_mst (server.c:763) ==32258== by 0x4041C51: receive_ready (connection.c:1192) ==32258== by 0x405A868: GNUNET_SCHEDULER_run (scheduler.c:648) ==32258== ==32258== ==32258== 517,686 (514,486 direct, 3,200 indirect) bytes in 1,234 blocks are definitely lost in loss record 18 of 18 ==32258== at 0x4022525: malloc (vg_replace_malloc.c:149) ==32258== by 0x403D60C: GNUNET_xmalloc_unchecked_ (common_allocation.c:132) ==32258== by 0x403D6B9: GNUNET_xmalloc_ (common_allocation.c:61) ==32258== by 0x804C40E: transmit_to_peer (gnunet-service-transport.c:2212) ==32258== by 0x804CB3F: setup_new_neighbour (gnunet-service-transport.c:3424) ==32258== by 0x804CDA4: handle_request_connect (gnunet-service-transport.c:5810) ==32258== by 0x405B630: GNUNET_SERVER_inject (server.c:688) ==32258== by 0x405B786: client_message_tokenizer_callback (server.c:902) ==32258== by 0x405C527: GNUNET_SERVER_mst_receive (server_mst.c:229) ==32258== by 0x405B085: process_mst (server.c:763) ==32258== by 0x4041C51: receive_ready (connection.c:1192) ==32258== by 0x405A868: GNUNET_SCHEDULER_run (scheduler.c:648) |
|
|
Transport api ==32255== 16 bytes in 1 blocks are definitely lost in loss record 2 of 4 ==32255== at 0x4022525: malloc (vg_replace_malloc.c:149) ==32255== by 0x404460C: GNUNET_xmalloc_unchecked_ (common_allocation.c:132) ==32255== by 0x40446B9: GNUNET_xmalloc_ (common_allocation.c:61) ==32255== by 0x404BCDF: GNUNET_CONTAINER_heap_create (container_heap.c:142) ==32255== by 0x4034B3B: GNUNET_TRANSPORT_connect (transport_api_new.c:1322) ==32255== by 0x804A3C0: run (gnunet-service-core.c:4730) ==32255== by 0x4065F67: service_task (service.c:1403) ==32255== by 0x4061868: GNUNET_SCHEDULER_run (scheduler.c:648) ==32255== by 0x4067E58: GNUNET_SERVICE_run (service.c:1622) ==32255== by 0x804A111: main (gnunet-service-core.c:4764) |
|
|
Leak from node 4444 fixed in SVN 15745. |
|
|
Another still present... ==11218== 459,202 (457,426 direct, 1,776 indirect) bytes in 987 blocks are definitely lost in loss record 18 of 18 ==11218== at 0x4022525: malloc (vg_replace_malloc.c:149) ==11218== by 0x403D6EC: GNUNET_xmalloc_unchecked_ (common_allocation.c:132) ==11218== by 0x403D799: GNUNET_xmalloc_ (common_allocation.c:61) ==11218== by 0x402A124: GNUNET_PEERINFO_iterate (peerinfo_api.c:666) ==11218== by 0x804CA0A: setup_new_neighbour (gnunet-service-transport.c:3421) ==11218== by 0x804CDA4: handle_request_connect (gnunet-service-transport.c:5816) ==11218== by 0x405B990: GNUNET_SERVER_inject (server.c:704) ==11218== by 0x405BAE6: client_message_tokenizer_callback (server.c:918) ==11218== by 0x405C947: GNUNET_SERVER_mst_receive (server_mst.c:229) ==11218== by 0x405B3E5: process_mst (server.c:779) ==11218== by 0x4041DD1: receive_ready (connection.c:1209) ==11218== by 0x405AB98: GNUNET_SCHEDULER_run (scheduler.c:648) |
|
|
==12494== 115,404 (81,240 direct, 34,164 indirect) bytes in 206 blocks are definitely lost in loss record 17 of 17 ==12494== at 0x4022525: malloc (vg_replace_malloc.c:149) ==12494== by 0x403D6EC: GNUNET_xmalloc_unchecked_ (common_allocation.c:132) ==12494== by 0x403D799: GNUNET_xmalloc_ (common_allocation.c:61) ==12494== by 0x4042457: GNUNET_CONNECTION_create_from_existing (connection.c:334) ==12494== by 0x404250D: GNUNET_CONNECTION_create_from_sockaddr (connection.c:1034) ==12494== by 0x4398AE0: tcp_plugin_send (plugin_transport_tcp.c:1480) ==12494== by 0x804BE90: try_transmission_to_peer (gnunet-service-transport.c:2144) ==12494== by 0x804D9F2: send_periodic_ping (gnunet-service-transport.c:4003) ==12494== by 0x405AB98: GNUNET_SCHEDULER_run (scheduler.c:648) ==12494== by 0x40612A8: GNUNET_SERVICE_run (service.c:1626) ==12494== by 0x804A024: main (gnunet-service-transport.c:7666) |
|
|
IMHO we have missing transmit continuation calls from tcp: Example: plugin->send calls: 171 (mq's created) calls to transmit continuation: 130 (mq's deleted in cont) directly deleted (send syserr): 0 deleted (no_addr): 0 difference: 41 Have to look in tcpplugin... |
|
|
The leak from 4452 typically occurs if some code calls GNUNET_SERVER_client_keep and never calls GNUNET_SERVER_client_drop. |
|
|
Leak in 0004451 might be fixed in SVN 15761. |
|
|
0004451 is still existing The issues is somehow related to addresses from peerinfo - Does not happen on a fresh peer - Does not happen if peerinfo is disabled Tried to reproduce it with 3 peers: One bootstrap server, 2 clients Could not reproduce it |
|
|
Found problem causing 0004451: During RequestConnects from core: Transport service sends messages to peers but disconnects from peer before transmit_send_continuation is called! messages with outstanding continuation calls are lost... |
|
|
Neighbour is deleted and send_cont==NULL before send_continuation can delete messages |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-06-16 11:43 | mrwiggles | New Issue | |
| 2011-06-16 11:43 | mrwiggles | Status | new => assigned |
| 2011-06-16 11:43 | mrwiggles | Assigned To | => Matthias Wachs |
| 2011-06-16 15:33 | Christian Grothoff | Severity | minor => major |
| 2011-06-16 16:26 | mrwiggles | Assigned To | Matthias Wachs => mrwiggles |
| 2011-06-16 18:08 | mrwiggles | Note Added: 0004381 | |
| 2011-06-16 18:08 | mrwiggles | Note Edited: 0004381 | |
| 2011-06-16 18:09 | mrwiggles | Assigned To | mrwiggles => Christian Grothoff |
| 2011-06-17 09:46 | Christian Grothoff | Assigned To | Christian Grothoff => Matthias Wachs |
| 2011-06-17 12:07 | Christian Grothoff | Priority | normal => urgent |
| 2011-06-20 16:09 | mrwiggles | Note Added: 0004443 | |
| 2011-06-20 16:09 | mrwiggles | Note Added: 0004444 | |
| 2011-06-22 14:15 | Christian Grothoff | Note Added: 0004450 | |
| 2011-06-22 15:06 | mrwiggles | Note Added: 0004451 | |
| 2011-06-22 15:06 | mrwiggles | Note Added: 0004452 | |
| 2011-06-22 17:39 | Matthias Wachs | Note Added: 0004453 | |
| 2011-06-23 12:30 | Christian Grothoff | Relationship added | duplicate of 0001719 |
| 2011-06-23 12:40 | Christian Grothoff | Note Added: 0004462 | |
| 2011-06-23 12:57 | Christian Grothoff | Note Added: 0004463 | |
| 2011-06-24 17:28 | Matthias Wachs | Note Added: 0004465 | |
| 2011-06-28 11:43 | Matthias Wachs | Note Added: 0004468 | |
| 2011-06-28 11:44 | Matthias Wachs | Status | assigned => confirmed |
| 2011-06-28 13:36 | Matthias Wachs | Note Added: 0004469 | |
| 2011-06-28 14:34 | Matthias Wachs | Status | confirmed => closed |
| 2011-06-28 14:34 | Matthias Wachs | Resolution | open => fixed |
| 2011-06-28 14:34 | Matthias Wachs | Additional Information Updated |
