View Issue Details

IDProjectCategoryView StatusLast Update
0001622GNUnetotherpublic2010-12-23 23:50
Reportermrwiggles Assigned ToChristian Grothoff  
PriorityhighSeveritycrashReproducibilitysometimes
Status closedResolutionfixed 
Summary0001622: Core API segfault
DescriptionAfter 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 InformationProgram 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
TagsNo tags attached.
Attached Files
core_api.valgrind (7,941 bytes)

Activities

mrwiggles

2010-11-18 12:16

reporter   ~0004172

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

Christian Grothoff

2010-11-18 22:28

manager   ~0004173

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...

mrwiggles

2010-11-19 12:32

reporter   ~0004179

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)

Christian Grothoff

2010-11-19 13:31

manager   ~0004180

Fixed in SVN 13749.

Issue History

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