View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001728 | GNUnet | util library | public | 2011-07-04 13:59 | 2011-08-03 15:49 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | Due Date | |
| Priority | normal | Severity | crash | Reproducibility | have not tried |
| Status | closed | Resolution | unable to reproduce | ||
| Product Version | Git master | ||||
| Summary | 0001728: Assertion failed at connection.c:1723. | ||||
| Description | Jul 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 Information | http://gnunet.org:8010/builders/debian-amd64-grothoff/builds/1521/steps/tests%20fs/logs/stdio | ||||
| Tags | No tags attached. | ||||
| Fixed in SVN 15867. | |
| 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 | |
| Eh, nothing *should* have changed. Theoretically. But there were "bugfixes" in util... | |
| 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. | |
| 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. | |
| (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) | |
| How do you reproduce this? I cannot seem to reproduce this on my system. | |
| Cannot reproduce this anymore. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-07-04 13:59 | Christian Grothoff | New Issue | |
| 2011-07-07 09:30 | Christian Grothoff | Note Added: 0004477 | |
| 2011-07-07 09:30 | Christian Grothoff | Status | new => resolved |
| 2011-07-07 09:30 | Christian Grothoff | Resolution | open => fixed |
| 2011-07-07 09:30 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2011-07-07 12:38 | mrwiggles | Note Added: 0004479 | |
| 2011-07-07 12:38 | mrwiggles | Status | resolved => feedback |
| 2011-07-07 12:38 | mrwiggles | Resolution | fixed => reopened |
| 2011-07-07 21:10 | Christian Grothoff | Note Added: 0004484 | |
| 2011-07-07 21:13 | Christian Grothoff | Note Added: 0004485 | |
| 2011-07-07 21:13 | Christian Grothoff | Status | feedback => resolved |
| 2011-07-07 21:13 | Christian Grothoff | Resolution | reopened => fixed |
| 2011-07-08 12:36 | Matthias Wachs | Note Added: 0004493 | |
| 2011-07-08 12:36 | Matthias Wachs | Status | resolved => feedback |
| 2011-07-08 12:36 | Matthias Wachs | Resolution | fixed => reopened |
| 2011-07-08 12:36 | Matthias Wachs | Note Edited: 0004493 | |
| 2011-07-08 12:39 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2011-07-08 12:42 | Matthias Wachs | Note Added: 0004494 | |
| 2011-07-15 13:18 | Christian Grothoff | Status | feedback => assigned |
| 2011-07-15 13:18 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2011-07-19 13:22 | Christian Grothoff | Note Added: 0004531 | |
| 2011-07-19 13:22 | Christian Grothoff | Status | assigned => feedback |
| 2011-08-03 15:49 | root | Note Added: 0004545 | |
| 2011-08-03 15:49 | root | Status | feedback => closed |
| 2011-08-03 15:49 | root | Resolution | reopened => unable to reproduce |