View Issue Details

IDProjectCategoryView StatusLast Update
0001728GNUnetutil librarypublic2011-08-03 17:49
ReporterChristian Grothoff Assigned ToChristian Grothoff  
PrioritynormalSeveritycrashReproducibilityhave not tried
Status closedResolutionunable to reproduce 
Product VersionGit master 
Summary0001728: Assertion failed at connection.c:1723.
DescriptionJul 04 15:12:07-272853 test-fs-search-persistence-12994 ERROR Assertion failed at connection.c:1723.
/bin/sh: line 5: 12994 Aborted ${dir}$tst
FAIL: test_fs_search_persistence
Additional Informationhttp://gnunet.org:8010/builders/debian-amd64-grothoff/builds/1521/steps/tests%20fs/logs/stdio
TagsNo tags attached.

Activities

Christian Grothoff

2011-07-07 11:30

manager   ~0004477

Fixed in SVN 15867.

mrwiggles

2011-07-07 14:38

reporter   ~0004479

This happens often now... This one comes from core service when connecting peers using the testing framework. Did something change I should be aware of?

#0 0x00007f6c5cafb935 in raise () from /lib64/libc.so.6
#1 0x00007f6c5cafcdb6 in abort () from /lib64/libc.so.6
#2 0x00007f6c5d912572 in GNUNET_CONNECTION_notify_transmit_ready_cancel (h=0x1da6648) at connection.c:1723
#3 0x00007f6c5d92e71a in handle_client_disconnect (cls=0x1d7d910, client=0x1da2640) at server_nc.c:192
#4 0x00007f6c5d92daf7 in GNUNET_SERVER_client_disconnect (client=0x1da2640) at server.c:1205
#5 0x00007f6c5d92d46d in process_incoming (cls=0x1da2640, buf=0x7fff86b17ff0, available=0, addr=0x1d95830, addrlen=2, errCode=0)
    at server.c:878
#6 0x00007f6c5d91143e in receive_ready (cls=0x1da65c0, tc=0x7fff86b28070) at connection.c:1213
#7 0x00007f6c5d92b22f in run_ready (rs=0x1d762c0, ws=0x1d7d460) at scheduler.c:648
#8 0x00007f6c5d92b635 in GNUNET_SCHEDULER_run (task=0x7f6c5d932314 <service_task>, task_cls=0x7fff86b28320) at scheduler.c:795
#9 0x00007f6c5d933253 in GNUNET_SERVICE_run (argc=3, argv=0x7fff86b28548, serviceName=0x40ba12 "core", opt=GNUNET_SERVICE_OPTION_NONE,
    task=0x40ac33 <run>, task_cls=0x0) at service.c:1627
#10 0x000000000040b034 in main (argc=3, argv=0x7fff86b28548) at gnunet-service-core.c:4765

Christian Grothoff

2011-07-07 23:10

manager   ~0004484

Eh, nothing *should* have changed. Theoretically. But there were "bugfixes" in util...

Christian Grothoff

2011-07-07 23:13

manager   ~0004485

Another try at fixing this is in 15884. It MAY just be that the code is blowing up now because we're more strictly checking that the shutdown sequences are in order.

Matthias Wachs

2011-07-08 14:36

reporter   ~0004493

Last edited: 2011-07-08 14:36

seems not to be fixed in revision 15893:

src/fs$ ./perf_gnunet_service_fs_p2p_trust :

Jul 08 14:34:39-957400 core-144614 ERROR Assertion failed at connection.c:1723.

Matthias Wachs

2011-07-08 14:42

reporter   ~0004494

(gdb) bt
#0 0x00007fbe411c7d05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007fbe411cbab6 in abort () at abort.c:92
#2 0x00007fbe419c74cf in GNUNET_CONNECTION_notify_transmit_ready_cancel (h=0x2574688) at connection.c:1723
#3 0x00007fbe419c03ce in GNUNET_CLIENT_notify_transmit_ready_cancel (th=0x258d520) at client.c:982
#4 0x00007fbe419bf3fa in GNUNET_CLIENT_disconnect (sock=0x25746e0, finish_pending_write=0) at client.c:442
#5 0x00007fbe41bf7ce3 in reconnect_later (h=0x2574060) at core_api.c:495
#6 0x00007fbe41bf90a0 in main_notify_handler (cls=0x2574060, msg=0x0) at core_api.c:871
#7 0x00007fbe419bf5b7 in receive_helper (cls=0x25746e0, buf=0x0, available=0, addr=0x0, addrlen=0, errCode=0)
    at client.c:509
#8 0x00007fbe419c60a2 in signal_timeout (sh=0x2574600) at connection.c:1120
#9 0x00007fbe419c624a in receive_ready (cls=0x2574600, tc=0x7fff7c271520) at connection.c:1178
#10 0x00007fbe419dff82 in run_ready (rs=0x2559430, ws=0x255f0e0) at scheduler.c:648
#11 0x00007fbe419e0376 in GNUNET_SCHEDULER_run (task=0x7fbe419e71d3 <service_task>, task_cls=0x7fff7c2717c0)
    at scheduler.c:795
#12 0x00007fbe419e8110 in GNUNET_SERVICE_run (argc=3, argv=0x7fff7c2719d8, serviceName=0x40f527 "fs",
    opt=GNUNET_SERVICE_OPTION_NONE, task=0x4041a5 <run>, task_cls=0x0) at service.c:1627
#13 0x0000000000404369 in main (argc=3, argv=0x7fff7c2719d8) at gnunet-service-fs.c:621
(gdb)

Christian Grothoff

2011-07-19 15:22

manager   ~0004531

How do you reproduce this? I cannot seem to reproduce this on my system.

root

2011-08-03 17:49

administrator   ~0004545

Cannot reproduce this anymore.

Issue History

Date Modified Username Field Change
2011-07-04 15:59 Christian Grothoff New Issue
2011-07-07 11:30 Christian Grothoff Note Added: 0004477
2011-07-07 11:30 Christian Grothoff Status new => resolved
2011-07-07 11:30 Christian Grothoff Resolution open => fixed
2011-07-07 11:30 Christian Grothoff Assigned To => Christian Grothoff
2011-07-07 14:38 mrwiggles Note Added: 0004479
2011-07-07 14:38 mrwiggles Status resolved => feedback
2011-07-07 14:38 mrwiggles Resolution fixed => reopened
2011-07-07 23:10 Christian Grothoff Note Added: 0004484
2011-07-07 23:13 Christian Grothoff Note Added: 0004485
2011-07-07 23:13 Christian Grothoff Status feedback => resolved
2011-07-07 23:13 Christian Grothoff Resolution reopened => fixed
2011-07-08 14:36 Matthias Wachs Note Added: 0004493
2011-07-08 14:36 Matthias Wachs Status resolved => feedback
2011-07-08 14:36 Matthias Wachs Resolution fixed => reopened
2011-07-08 14:36 Matthias Wachs Note Edited: 0004493
2011-07-08 14:39 Christian Grothoff Assigned To Christian Grothoff =>
2011-07-08 14:42 Matthias Wachs Note Added: 0004494
2011-07-15 15:18 Christian Grothoff Status feedback => assigned
2011-07-15 15:18 Christian Grothoff Assigned To => Christian Grothoff
2011-07-19 15:22 Christian Grothoff Note Added: 0004531
2011-07-19 15:22 Christian Grothoff Status assigned => feedback
2011-08-03 17:49 root Note Added: 0004545
2011-08-03 17:49 root Status feedback => closed
2011-08-03 17:49 root Resolution reopened => unable to reproduce