UDP crashes on port recycling

[Martin Decky]

When running nettest1 (against local netecho), the UDP server crashes after the first roundtrip of sendto/recvfrom. The indirect cause is the recycling of the source UDP port which causes either memory corruption or a race condition.

Output of netecho:

Socket 212359 listenning at 7
recvfrom()
Socket 212359 received 27 bytes from 127.0.0.1:1025
Networking test 1 - sockets
sendto()
recvfrom()
Socket 212359 received 27 bytes from 127.0.0.1:1025
Networking test 1 - sockets
sendto()
recvfrom()

Output of nettest1:

Starting tests
1 sockets, 1 messages
Create    *    Sendto and recvfrom    *    Close    *    OK
Create    *    Sendto    *    Recvfrom

Kernel log:

Assertion failed (sess != NULL) in file "generic/async.c", line 2070.
Assertion failed (sess != NULL) in file "generic/async.c", line 2070.
0x0000000000637f00: 0x000000000001c735()
0x0000000000637f30: 0x000000000001c817()
0x0000000000637f50: 0x0000000000014cc9()
0x0000000000637fd0: 0x0000000000001ccf()
0x0000000000637ff0: 0x000000000000769d()
-- end of stack trace --
taskmon: Task 31 fault in thread 0xffff800007b3daf8.
taskmon: Executing /app/taskdump -t 31
Task Dump Utility
Dumping task 'udp' (task ID 31).
failed opening file
Loaded symbol table from /srv/udp

Threads:
 [1] hash: 0xffff800007b3daf8
Thread 0xffff800007b3daf8: PC = 0x0000000000011083 (malloc_internal+547). FP = 0x0000000000432e20
  0x0000000000432e20: 0x0000000000011083 (malloc_internal+547)
  0x0000000000432eb0: 0x0000000000007fd7 (fibril_mutex_lock+87)
  0x0000000000432f00: 0x00000000000017db (udp_free_sock_data+18446744073709550667)
  0x0000000000432f50: 0x0000000000002f85 (udp_uc_receive+85)
  0x0000000000432fd0: 0x0000000000001c6b (udp_sock_recv_fibril+203)
  0x0000000000432ff0: 0x000000000000769d (fibril_main+29)

Address space areas:
 [1] flags: R-XC base: 0x0000000000001000 size: 155648
 [2] flags: RW-C base: 0x0000000000027000 size: 4096
 [3] flags: RW-C base: 0x0000000000028000 size: 8192
 [4] flags: RW-C base: 0x000000000002b000 size: 1048576
 [5] flags: RW-C base: 0x000000000012c000 size: 16384
 [6] flags: RW-C base: 0x0000000000131000 size: 1048576
 [7] flags: RW-C base: 0x0000000000232000 size: 1048576
 [8] flags: RW-C base: 0x0000000000333000 size: 1048576
 [9] flags: RW-C base: 0x0000000000434000 size: 8192
 [10] flags: RW-C base: 0x0000000000437000 size: 1048576
 [11] flags: RW-C base: 0x0000000000538000 size: 1048576
 [12] flags: RW-C base: 0x0000000000639000 size: 8192
 [13] flags: RW-C base: 0x000000000063c000 size: 1048576
 [14] flags: R-XC base: 0x0000000070001000 size: 126976
 [15] flags: RW-C base: 0x0000000070020000 size: 4096
 [16] flags: RW-C base: 0x0000000070021000 size: 8192
 [17] flags: RW-C base: 0x0000000070024000 size: 1048576
 [18] flags: RW-C base: 0x0000000070125000 size: 1048576
 [19] flags: RW-C base: 0x00007ffffff00000 size: 1048576

[Martin Decky]

The bug has been temporarily worked around in mainline,1766. A proper solution is still required.

[Martin Decky]

A more-or-less proper workaround was implemented in mainline,1767. However, it seems that the socket API does not recycle unused ports at all.

[Jiri Svoboda]

Great! I think this is maybe what I was hitting with the DNS resolver. I'll try it with your fix if it helps.