View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002071 | GNUnet | cadet service | public | 2012-01-15 21:31 | 2012-02-28 11:05 |
| Reporter | Christian Grothoff | Assigned To | Bart Polot | ||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.9.2 | Fixed in Version | 0.9.2 | ||
| Summary | 0002071: assertion failed at mesh_api.c:929 | ||||
| Description | Starting program: /home/grothoff/bin/gnunet-daemon-exit -L DEBUG Jan 15 21:28:56-212708 mesh-api-811 DEBUG mesh: GNUNET_MESH_connect() Jan 15 21:28:56-212760 mesh-api-811 DEBUG mesh: app 16 Jan 15 21:28:56-212768 mesh-api-811 DEBUG mesh: app 17 Jan 15 21:28:56-212775 mesh-api-811 DEBUG mesh: Sending 26 bytes long message 5 types and 2 apps Jan 15 21:28:56-212790 mesh-api-811 DEBUG mesh: GNUNET_MESH_connect() END Jan 15 21:28:56-213251 mesh-api-811 DEBUG mesh: Send packet() Buffer 26 Jan 15 21:28:56-213280 mesh-api-811 DEBUG mesh: total size: 26 Jan 15 21:28:56-213292 mesh-api-811 DEBUG mesh: Send packet() END Jan 15 21:29:04-664618 mesh-api-811 DEBUG mesh: received a message type 261 from MESH Jan 15 21:29:04-664646 gnunet-daemon-exit-811 DEBUG mesh: Got a data message! Breakpoint 1, process_incoming_data (h=0x612140, message=0x7fffffffdd10) at mesh_api.c:929 929 GNUNET_break (0); (gdb) (gdb) ba #0 process_incoming_data (h=0x612140, message=0x7fffffffdd10) at mesh_api.c:929 #1 0x00007ffff756508d in msg_received (cls=0x612140, msg=0x7fffffffdd10) at mesh_api.c:999 #2 0x00007ffff777a9f3 in receive_task (cls=0x612a00, tc=0x7fffffffde40) at client.c:551 #3 0x00007ffff77ad682 in run_ready (rs=0x60f210, ws=0x60f2a0) at scheduler.c:684 #4 0x00007ffff77ade67 in GNUNET_SCHEDULER_run (task=0x7ffff77a6e98 <program_main>, task_cls=0x7fffffffe0f0) at scheduler.c:874 #5 0x00007ffff77a77e1 in GNUNET_PROGRAM_run (argc=3, argv=0x7fffffffe2d8, binaryName=0x409395 "gnunet-daemon-exit", binaryHelp=0x409360 "Daemon to run to provide an IP exit node for the VPN", options=0x4093c0, task=0x407e72 <run>, task_cls=0x0) at program.c:250 #6 0x0000000000408842 in main (argc=3, argv=0x7fffffffe2d8) at gnunet-daemon-exit.c:2292 (gdb) print type $3 = 261 (gdb) print t $4 = (struct GNUNET_MESH_Tunnel *) 0x0 (gdb) print *h $6 = {client = 0x612a00, message_handlers = 0x60a4c0, applications = 0x60a760, tunnels_head = 0x0, tunnels_tail = 0x0, new_tunnel = 0x406f2e <new_tunnel>, cleaner = 0x40700c <clean_tunnel>, th = 0x0, cls = 0x0, th_head = 0x0, th_tail = 0x0, next_tid = 2147483648, n_handlers = 5, n_applications = 2, max_queue_size = 42, in_receive = 1, npackets = 0, cfg = 0x60be80, reconnect_time = {rel_value = 1}} | ||||
| Tags | No tags attached. | ||||
| child of | 0002064 | closed | Christian Grothoff | new VPN service (working with new exit/dns services) needs to be fully implemented and tested |
|
|
So, the API received a multicast packet from an unknow tunnel, unknown because there are no known tunnels. Was it supposed to be connected to any tunnel? Was it connected to a tunnel before and it disconnected from it? Did an api<->service reconnection happen at some point? |
|
|
Here's the full output with valgrind: grothoff@spec:~$ valgrind gnunet-daemon-exit -L DEBUG ==32348== Memcheck, a memory error detector ==32348== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==32348== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==32348== Command: gnunet-daemon-exit -L DEBUG ==32348== Jan 17 19:32:52-984989 mesh-api-32348 DEBUG mesh: GNUNET_MESH_connect() Jan 17 19:32:53-021223 mesh-api-32348 DEBUG mesh: app 16 Jan 17 19:32:53-023614 mesh-api-32348 DEBUG mesh: app 17 Jan 17 19:32:53-026108 mesh-api-32348 DEBUG mesh: Sending 26 bytes long message 5 types and 2 apps Jan 17 19:32:53-036891 mesh-api-32348 DEBUG mesh: GNUNET_MESH_connect() END Jan 17 19:32:53-062554 mesh-api-32348 DEBUG mesh: Send packet() Buffer 26 Jan 17 19:32:53-065078 mesh-api-32348 DEBUG mesh: total size: 26 Jan 17 19:32:53-065814 mesh-api-32348 DEBUG mesh: Send packet() END Jan 17 19:33:05-133497 mesh-api-32348 DEBUG mesh: received a message type 261 from MESH Jan 17 19:33:05-138690 gnunet-daemon-exit-32348 DEBUG mesh: Got a data message! Jan 17 19:33:05-140604 gnunet-daemon-exit-32348 ERROR Assertion failed at mesh_api.c:929. Jan 17 19:33:05-141548 mesh-api-32348 DEBUG mesh: message processed Jan 17 19:33:08-079235 mesh-api-32348 DEBUG mesh: received a message type 261 from MESH Jan 17 19:33:08-079510 gnunet-daemon-exit-32348 DEBUG mesh: Got a data message! Jan 17 19:33:08-079809 gnunet-daemon-exit-32348 ERROR Assertion failed at mesh_api.c:929. Jan 17 19:33:08-080065 mesh-api-32348 DEBUG mesh: message processed What was supposed to happen was that the VPN created a tunnel to the EXIT service (by-type) and then the VPN sends a message via that tunnel to EXIT. Later, exit would then send a reply (but I don't think it quite got to that part). |
|
|
Can you try again with the extra debug lines from r19217? Thought for the future: maybe we should somehow specify the client/service target of a tunnel on creation. Right now, all clients in a peer will receive an incoming tunnel notification when a tunnel is created, which can cause trouble/inefficiency when only some clients close it and other leave it open. Should I open a bug with this? |
|
|
Ok, here is how to try it: 1) start a peer (or manually start services, you don't even need transport, and core is only good to make mesh less bitchy) with mesh, exit and vpn. The only configuration change (which you can do in ~/.gnunet/gnunet.conf) is to set EXIT_IPV4 and EXIT_IPV6 to YES in the [exit] section). 2) run gnunet-vpn -t -i SOMEIPADDRESS (I use gnunet.org's IP for testing), the output is some OTHER IP (in the 10.11.x.x-range). 3) run 'wget' on the 10.11.x.x-IP address to cause TCP traffic (which should now go via the vpn-tun to the vpn-service to mesh to exit to exit-tun to gnunet.org and then ultimately back to wget). Usually various parts around mesh (mesh_api.c, mesh service) crash when I do this. |
|
|
Workaround implemented in r19233 and 19244, bigger picture changes might be necessary. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-01-15 21:31 | Christian Grothoff | New Issue | |
| 2012-01-15 21:31 | Christian Grothoff | Status | new => assigned |
| 2012-01-15 21:31 | Christian Grothoff | Assigned To | => Bart Polot |
| 2012-01-15 21:47 | Christian Grothoff | Target Version | => 0.9.2 |
| 2012-01-15 21:51 | Christian Grothoff | Relationship added | child of 0002064 |
| 2012-01-17 18:49 | Bart Polot | Note Added: 0005279 | |
| 2012-01-17 18:49 | Bart Polot | Status | assigned => feedback |
| 2012-01-17 19:36 | Christian Grothoff | Note Added: 0005280 | |
| 2012-01-17 19:36 | Christian Grothoff | Status | feedback => assigned |
| 2012-01-17 20:50 | Bart Polot | Note Added: 0005281 | |
| 2012-01-17 21:23 | Christian Grothoff | Note Added: 0005283 | |
| 2012-01-18 16:13 | Bart Polot | Note Added: 0005285 | |
| 2012-01-18 16:13 | Bart Polot | Status | assigned => resolved |
| 2012-01-18 16:13 | Bart Polot | Fixed in Version | => Git master |
| 2012-01-18 16:13 | Bart Polot | Resolution | open => fixed |
| 2012-01-22 21:17 | Christian Grothoff | Fixed in Version | Git master => 0.9.2 |
| 2012-02-28 11:05 | Christian Grothoff | Status | resolved => closed |
| 2014-05-09 18:34 | Christian Grothoff | Category | mesh service => cadet service |
