View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001622 | GNUnet | other | public | 2010-11-18 11:42 | 2010-12-23 23:50 |
| Reporter | mrwiggles | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | crash | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Summary | 0001622: Core API segfault | ||||
| Description | After running for around 5 minutes this pops up intermittently on (at least one) test machine, when running DHT tests. At this point in the code th is some random invalid memory address. This means that pr->pending_head from a couple lines above must somehow get corrupted(?). I don't think the DHT service (which is the one that crashes) does anything *strange*, but I doubt core api should get into this state anyhow... | ||||
| Additional Information | Program terminated with signal 11, Segmentation fault. [New process 29214] #0 0x00007f02fb0426bf in main_notify_handler (cls=0x16eba40, msg=0x7fffd74e7690) at core_api.c:1142 1142 if (ntohs (smr->smr_id) != th->smr_id) (gdb) bt #0 0x00007f02fb0426bf in main_notify_handler (cls=0x16eba40, msg=0x7fffd74e7690) at core_api.c:1142 #1 0x00007f02fa60af22 in receive_task (cls=0x16e9b30, tc=<value optimized out>) at client.c:529 | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
|
|
On further inspection it seems that the PeerRecord pr is somehow corrupted. I suppose it could be a memory corruption from somewhere else (like the DHT service). 1140 #endif 1141 th = pr->pending_head; 1142 if (ntohs (smr->smr_id) != th->smr_id) 1143 { 1144 /* READY message is for expired or cancelled message, 1145 ignore! (we should have already sent another request) */ 1146 break; (gdb) print pr->pending_head $2 = (struct GNUNET_CORE_TransmitHandle *) 0x91 (gdb) print pr $3 = (struct PeerRecord *) 0x7f4fb0decb10 (gdb) print *pr Cannot access memory at address 0x7f4fb0decb10 (gdb) print pr->pending_head Cannot access memory at address 0x7f4fb0decb68 (gdb) print th $4 = (struct GNUNET_CORE_TransmitHandle *) 0x0 (gdb) print pr $5 = (struct PeerRecord *) 0x7f4fb0decb10 (gdb) print *pr Cannot access memory at address 0x7f4fb0decb10 |
|
|
Looks like some memory corruption *somewhere*, especially since the only place where I can find a PeerRecord being free'd includes its removal from the hash map. Now, if this only occurs with a very large number of peers, one thing to consider is the possibility of broken system memory. This would NOT be the first time we get a crash due to hardware failures (and 12 GB give quite some room for bit-errors...). So valgrind and/or memtest86... |
|
|
Significant part of valgrind trace: ==24019== Invalid write of size 8 ==24019== at 0x502BDA7: mark_control_message_sent (core_api.c:530) ==24019== by 0x502BC9B: reconnect_later (core_api.c:481) ==24019== by 0x502C222: transmit_message (core_api.c:644) ==24019== by 0x5A4C409: client_notify (client.c:784) ==24019== by 0x5A522F5: connect_error (connection.c:1376) ==24019== by 0x5A69AF3: run_ready (scheduler.c:644) ==24019== by 0x5A69F02: GNUNET_SCHEDULER_run (scheduler.c:786) ==24019== by 0x5A70BB3: GNUNET_SERVICE_run (service.c:1567) ==24019== by 0x40A9E8: main (gnunet-service-dht.c:4790) ==24019== Address 0x7f68520 is 24 bytes inside a block of size 64 free'd ==24019== at 0x4C2130F: free (vg_replace_malloc.c:323) ==24019== by 0x5A4CD57: GNUNET_xfree_ (common_allocation.c:156) ==24019== by 0x502B849: disconnect_and_free_peer_entry (core_api.c:417) ==24019== by 0x5A56740: GNUNET_CONTAINER_multihashmap_iterate (container_multihashmap.c:211) ==24019== by 0x502BBF9: reconnect_later (core_api.c:471) ==24019== by 0x502C222: transmit_message (core_api.c:644) ==24019== by 0x5A4C409: client_notify (client.c:784) ==24019== by 0x5A522F5: connect_error (connection.c:1376) ==24019== by 0x5A69AF3: run_ready (scheduler.c:644) ==24019== by 0x5A69F02: GNUNET_SCHEDULER_run (scheduler.c:786) ==24019== by 0x5A70BB3: GNUNET_SERVICE_run (service.c:1567) ==24019== by 0x40A9E8: main (gnunet-service-dht.c:4790) |
|
|
Fixed in SVN 13749. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-11-18 11:42 | mrwiggles | New Issue | |
| 2010-11-18 11:46 | mrwiggles | Description Updated | |
| 2010-11-18 11:46 | mrwiggles | Status | new => assigned |
| 2010-11-18 11:46 | mrwiggles | Assigned To | => Christian Grothoff |
| 2010-11-18 12:16 | mrwiggles | Note Added: 0004172 | |
| 2010-11-18 22:28 | Christian Grothoff | Note Added: 0004173 | |
| 2010-11-19 12:31 | mrwiggles | File Added: core_api.valgrind | |
| 2010-11-19 12:32 | mrwiggles | Note Added: 0004179 | |
| 2010-11-19 13:31 | Christian Grothoff | Note Added: 0004180 | |
| 2010-11-19 13:31 | Christian Grothoff | Status | assigned => resolved |
| 2010-11-19 13:31 | Christian Grothoff | Resolution | open => fixed |
| 2010-12-23 23:50 | Christian Grothoff | Status | resolved => closed |