Re: RTnet bind failed socket again
- Den 4 jun 2019, på kl 9:45, Per Öberg p...@wolfram.com skrev: > - Den 3 jun 2019, på kl 17:33, Jan Kiszka jan.kis...@siemens.com skrev: > > On 03.06.19 11:10, Per Oberg via Xenomai wrote: > > > - Den 3 jun 2019, på kl 11:06, xenomai xenomai@xenomai.org skrev: > > >> Hi, > > >> My program opens a RTnet socket successfully but the program gets killed > > >> by a different issue that has nothing to do with this. However, the > > >> RTnet socket is still bound. If I try to start the program again i get > > >> the error "Address already in use". If it would be a normal unix socket > > >> I would simply call it with SO_REUSEADDR but this is not possible with > > >> RTnet from what I understand. > >> I tried this and failed miserably. That said, I'm also interested in the > >> answer > > > to this question. > > >> My question is why the socket is not unbound after the binding process > > >> is killed and if there is a way to reclaim this socket. By the way, it > > >> has to be this socket since the communication partner expects the server > > >> to listen on this exact port. > > >> Cheers, > > >> Johannes > > > Per Öberg > > Are we talking about UDP in both cases? > I use UDP, yes. But I had no problems with the UDP part. Sorry, just remembered that the socket is created using SOCK_DGRAM, so I it is a UDP socket already when I call this (I got the order of things wrong in my head...) I tried using a SOCK_STREAM socket, and for this case there was no kernel bug. > The problem I had was regarding the use of setsockopt. Because I test the code > on a regular linux machine the lingering of the sockets after killing the > application can be annoying. From what you describe below, SO_REUSEADDR should > not be necessary for this case (did I get that correctly? ). > Because I use the posix skin, and because it was necessary in regular linux, i > started out using it in the common code base but I never managed to get it > working in RT so I removed it again. > I used something like: > > int reuseSetting = 1; > > setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, , > > sizeof(int); > Or even (because I use both rt and not rt sockets in the same code and I got > the > feeling that the automatic handling of this didn't quite work out.) >> __cobalt_setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, , > > sizeof(int); > This gave me: > -- > 70642.91] [Xenomai] switching App Thread to secondary mode after exception > #14 in kernel-space at 0xa0281787 (pid 633) > [70642.667326] BUG: unable to handle kernel paging request at 7fe06ff84d20 > [70642.667948] IP: [] rt_ip_ioctl+0x27/0x120 [rtipv4] > [70642.668566] PGD 8002631e7067 > [70642.668575] PUD 24a07d067 > [70642.669184] PMD 260cab067 > [70642.669189] PTE 80023b6cc067 > [70642.669805] > [70642.670403] Oops: 0001 [#5] PREEMPT SMP > [70642.670989] Modules linked in: rtudp rtipv4 intel_powerclamp intel_rapl > coretemp rt_igb e1000e i915 rtnet pcan(O) video fan thermal_sys > [70642.671629] CPU: 3 PID: 633 Comm: App Thread Tainted: G D W O > 4.9.90-xeno-cobolt #1 > [70642.672239] Hardware name: Default string Default string/SKYBAY, BIOS > 5.0.1.1 > 04/18/2016 > [70642.672854] I-pipe domain: Linux > [70642.673459] task: 880263231b00 task.stack: c90001798000 > [70642.674066] RIP: 0010:[] [] > rt_ip_ioctl+0x27/0x120 [rtipv4] > [70642.674683] RSP: 0018:c9000179bda8 EFLAGS: 00010246 > [70642.675300] RAX: 0007 RBX: 40180021 RCX: > 88026dd8 > [70642.675923] RDX: 7fe06ff84d20 RSI: 40180021 RDI: > 880262a86800 > [70642.676544] RBP: c9000179bdd0 R08: 0050 R09: > 880263231b00 > [70642.677166] R10: 00e6 R11: R12: > 880262a86800 > [70642.677783] R13: 40180021 R14: 7fe06ff84d20 R15: > 62a86800 > [70642.678394] FS: 7fe06ff85700() GS:88026dd8() > knlGS: > [70642.679009] CS: 0010 DS: ES: CR0: 8005003b > [70642.679621] CR2: 7fe06ff84d20 CR3: 000261678000 CR4: > 00360630 > [70642.680233] Stack: > [70642.680838] a028c6f7 0001 81178cd0 > 880262a86800 > [70642.681464] 0003 c9000179be60 811725be > 0202 > [70642.682086] 880263231b00 88020010 c9000179be70 > c9000179be08 > [70642.682711] Call Trace: > [70642.683325] [] ? rt_udp_ioctl+0x67/0x8c [rtudp] > [70642.683949] [] ? CoBaLt_fcntl+0x20/0x20 > [70642.684573] [] rtdm_fd_ioctl+0xee/0x280 > [70642.685199] [] ? CoBaLt_fcntl+0x20/0x20 > [70642.685825] [] ? CoBaLt_fcntl+0x20/0x20 > [70642.686445] [] CoBaLt_ioctl+0xe/0x20 > [70642.687064] [] ipipe_syscall_hook+0x112/0x350 > [70642.687686] [] __ipipe_notify_syscall+0xc8/0x190 > [70642.688306] [] ipipe_handle_syscall+0x2a/0xb0 >
Re: RTnet bind failed socket again
On 04.06.19 10:24, Sebastian Smolorz wrote: Hi, on 04.06.2019 09:45, Per Oberg wrote: - Den 3 jun 2019, på kl 17:33, Jan Kiszka jan.kis...@siemens.com skrev: On 03.06.19 11:10, Per Oberg via Xenomai wrote: - Den 3 jun 2019, på kl 11:06, xenomai xenomai@xenomai.org skrev: Hi, My program opens a RTnet socket successfully but the program gets killed by a different issue that has nothing to do with this. However, the RTnet socket is still bound. If I try to start the program again i get the error "Address already in use". If it would be a normal unix socket I would simply call it with SO_REUSEADDR but this is not possible with RTnet from what I understand. I tried this and failed miserably. That said, I'm also interested in the answer to this question. My question is why the socket is not unbound after the binding process is killed and if there is a way to reclaim this socket. By the way, it has to be this socket since the communication partner expects the server to listen on this exact port. Cheers, Johannes Per Öberg Are we talking about UDP in both cases? I use UDP, yes. But I had no problems with the UDP part. The problem I had was regarding the use of setsockopt. Because I test the code on a regular linux machine the lingering of the sockets after killing the application can be annoying. From what you describe below, SO_REUSEADDR should not be necessary for this case (did I get that correctly? ). Because I use the posix skin, and because it was necessary in regular linux, i started out using it in the common code base but I never managed to get it working in RT so I removed it again. I used something like: int reuseSetting = 1; setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, , sizeof(int); Or even (because I use both rt and not rt sockets in the same code and I got the feeling that the automatic handling of this didn't quite work out.) __cobalt_setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, , sizeof(int); This gave me: -- 70642.91] [Xenomai] switching App Thread to secondary mode after exception #14 in kernel-space at 0xa0281787 (pid 633) [70642.667326] BUG: unable to handle kernel paging request at 7fe06ff84d20 [70642.667948] IP: [] rt_ip_ioctl+0x27/0x120 [rtipv4] [70642.668566] PGD 8002631e7067 [70642.668575] PUD 24a07d067 [70642.669184] PMD 260cab067 [70642.669189] PTE 80023b6cc067 [70642.669805] [70642.670403] Oops: 0001 [#5] PREEMPT SMP [70642.670989] Modules linked in: rtudp rtipv4 intel_powerclamp intel_rapl coretemp rt_igb e1000e i915 rtnet pcan(O) video fan thermal_sys [70642.671629] CPU: 3 PID: 633 Comm: App Thread Tainted: G D W O 4.9.90-xeno-cobolt #1 [70642.672239] Hardware name: Default string Default string/SKYBAY, BIOS 5.0.1.1 04/18/2016 [70642.672854] I-pipe domain: Linux [70642.673459] task: 880263231b00 task.stack: c90001798000 [70642.674066] RIP: 0010:[] [] rt_ip_ioctl+0x27/0x120 [rtipv4] [70642.674683] RSP: 0018:c9000179bda8 EFLAGS: 00010246 [70642.675300] RAX: 0007 RBX: 40180021 RCX: 88026dd8 [70642.675923] RDX: 7fe06ff84d20 RSI: 40180021 RDI: 880262a86800 [70642.676544] RBP: c9000179bdd0 R08: 0050 R09: 880263231b00 [70642.677166] R10: 00e6 R11: R12: 880262a86800 [70642.677783] R13: 40180021 R14: 7fe06ff84d20 R15: 62a86800 [70642.678394] FS: 7fe06ff85700() GS:88026dd8() knlGS: [70642.679009] CS: 0010 DS: ES: CR0: 8005003b [70642.679621] CR2: 7fe06ff84d20 CR3: 000261678000 CR4: 00360630 [70642.680233] Stack: [70642.680838] a028c6f7 0001 81178cd0 880262a86800 [70642.681464] 0003 c9000179be60 811725be 0202 [70642.682086] 880263231b00 88020010 c9000179be70 c9000179be08 [70642.682711] Call Trace: [70642.683325] [] ? rt_udp_ioctl+0x67/0x8c [rtudp] [70642.683949] [] ? CoBaLt_fcntl+0x20/0x20 [70642.684573] [] rtdm_fd_ioctl+0xee/0x280 [70642.685199] [] ? CoBaLt_fcntl+0x20/0x20 [70642.685825] [] ? CoBaLt_fcntl+0x20/0x20 [70642.686445] [] CoBaLt_ioctl+0xe/0x20 [70642.687064] [] ipipe_syscall_hook+0x112/0x350 [70642.687686] [] __ipipe_notify_syscall+0xc8/0x190 [70642.688306] [] ipipe_handle_syscall+0x2a/0xb0 [70642.688925] [] do_syscall_64+0x2d/0xf0 [70642.689514] [] entry_SYSCALL_64_after_swapgs+0x58/0xc6 [70642.690073] Code: 68 b8 eb b0 e8 ab 04 66 e1 81 fe 27 00 10 40 0f 84 c1 00 00 00 7e 73 81 fe 20 00 18 40 74 3c 81 fe 21 00 18 40 0f 85 a0 00 00 00 <8b> 02 8b 4a 10 4c 8b 42 08 8b 72 04 85 c0 0f 85 d6 00 00 00 83 [70642.691405] RIP [] rt_ip_ioctl+0x27/0x120 [rtipv4] [70642.692026] RSP [70642.692642] CR2: 7fe06ff84d20 [70642.693250] ---[ end trace
Re: RTnet bind failed socket again
Hi, on 04.06.2019 09:45, Per Oberg wrote: > - Den 3 jun 2019, på kl 17:33, Jan Kiszka jan.kis...@siemens.com skrev: > > > On 03.06.19 11:10, Per Oberg via Xenomai wrote: > > > > > > - Den 3 jun 2019, på kl 11:06, xenomai xenomai@xenomai.org skrev: > > > >> Hi, > > > >> My program opens a RTnet socket successfully but the program gets killed > > >> by a different issue that has nothing to do with this. However, the > > >> RTnet socket is still bound. If I try to start the program again i get > > >> the error "Address already in use". If it would be a normal unix socket > > >> I would simply call it with SO_REUSEADDR but this is not possible with > > >> RTnet from what I understand. > > >> I tried this and failed miserably. That said, I'm also interested in the > >> answer > > > to this question. > > > >> My question is why the socket is not unbound after the binding process > > >> is killed and if there is a way to reclaim this socket. By the way, it > > >> has to be this socket since the communication partner expects the server > > >> to listen on this exact port. > > > >> Cheers, > > > >> Johannes > > > > Per Öberg > > > > Are we talking about UDP in both cases? > > I use UDP, yes. But I had no problems with the UDP part. > > The problem I had was regarding the use of setsockopt. Because I test the > code on a regular linux machine the lingering of the sockets after killing > the application can be annoying. From what you describe below, SO_REUSEADDR > should not be necessary for this case (did I get that correctly? ). > > Because I use the posix skin, and because it was necessary in regular linux, > i started out using it in the common code base but I never managed to get it > working in RT so I removed it again. > > I used something like: > > > int reuseSetting = 1; > > setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, , > > sizeof(int); > > Or even (because I use both rt and not rt sockets in the same code and I got > the feeling that the automatic handling of this didn't quite work out.) > > __cobalt_setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, > > , sizeof(int); > > > This gave me: > -- > 70642.91] [Xenomai] switching App Thread to secondary mode after > exception #14 in kernel-space at 0xa0281787 (pid 633) > [70642.667326] BUG: unable to handle kernel paging request at 7fe06ff84d20 > [70642.667948] IP: [] rt_ip_ioctl+0x27/0x120 [rtipv4] > [70642.668566] PGD 8002631e7067 > [70642.668575] PUD 24a07d067 > [70642.669184] PMD 260cab067 > [70642.669189] PTE 80023b6cc067 > [70642.669805] > [70642.670403] Oops: 0001 [#5] PREEMPT SMP > [70642.670989] Modules linked in: rtudp rtipv4 intel_powerclamp intel_rapl > coretemp rt_igb e1000e i915 rtnet pcan(O) video fan thermal_sys > [70642.671629] CPU: 3 PID: 633 Comm: App Thread Tainted: G D W O > 4.9.90-xeno-cobolt #1 > [70642.672239] Hardware name: Default string Default string/SKYBAY, BIOS > 5.0.1.1 04/18/2016 > [70642.672854] I-pipe domain: Linux > [70642.673459] task: 880263231b00 task.stack: c90001798000 > [70642.674066] RIP: 0010:[] [] > rt_ip_ioctl+0x27/0x120 [rtipv4] > [70642.674683] RSP: 0018:c9000179bda8 EFLAGS: 00010246 > [70642.675300] RAX: 0007 RBX: 40180021 RCX: > 88026dd8 > [70642.675923] RDX: 7fe06ff84d20 RSI: 40180021 RDI: > 880262a86800 > [70642.676544] RBP: c9000179bdd0 R08: 0050 R09: > 880263231b00 > [70642.677166] R10: 00e6 R11: R12: > 880262a86800 > [70642.677783] R13: 40180021 R14: 7fe06ff84d20 R15: > 62a86800 > [70642.678394] FS: 7fe06ff85700() GS:88026dd8() > knlGS: > [70642.679009] CS: 0010 DS: ES: CR0: 8005003b > [70642.679621] CR2: 7fe06ff84d20 CR3: 000261678000 CR4: > 00360630 > [70642.680233] Stack: > [70642.680838] a028c6f7 0001 81178cd0 > 880262a86800 > [70642.681464] 0003 c9000179be60 811725be > 0202 > [70642.682086] 880263231b00 88020010 c9000179be70 > c9000179be08 > [70642.682711] Call Trace: > [70642.683325] [] ? rt_udp_ioctl+0x67/0x8c [rtudp] > [70642.683949] [] ? CoBaLt_fcntl+0x20/0x20 > [70642.684573] [] rtdm_fd_ioctl+0xee/0x280 > [70642.685199] [] ? CoBaLt_fcntl+0x20/0x20 > [70642.685825] [] ? CoBaLt_fcntl+0x20/0x20 > [70642.686445] [] CoBaLt_ioctl+0xe/0x20 > [70642.687064] [] ipipe_syscall_hook+0x112/0x350 > [70642.687686] [] __ipipe_notify_syscall+0xc8/0x190 > [70642.688306] [] ipipe_handle_syscall+0x2a/0xb0 > [70642.688925] [] do_syscall_64+0x2d/0xf0 > [70642.689514] [] entry_SYSCALL_64_after_swapgs+0x58/0xc6 > [70642.690073] Code: 68 b8 eb b0 e8 ab 04 66 e1 81 fe 27 00 10 40 0f 84 c1 00 > 00 00 7e 73
Re: RTnet bind failed socket again
On 04.06.19 09:45, Per Oberg wrote: - Den 3 jun 2019, på kl 17:33, Jan Kiszka jan.kis...@siemens.com skrev: On 03.06.19 11:10, Per Oberg via Xenomai wrote: - Den 3 jun 2019, på kl 11:06, xenomai xenomai@xenomai.org skrev: Hi, My program opens a RTnet socket successfully but the program gets killed by a different issue that has nothing to do with this. However, the RTnet socket is still bound. If I try to start the program again i get the error "Address already in use". If it would be a normal unix socket I would simply call it with SO_REUSEADDR but this is not possible with RTnet from what I understand. I tried this and failed miserably. That said, I'm also interested in the answer to this question. My question is why the socket is not unbound after the binding process is killed and if there is a way to reclaim this socket. By the way, it has to be this socket since the communication partner expects the server to listen on this exact port. Cheers, Johannes Per Öberg Are we talking about UDP in both cases? I use UDP, yes. But I had no problems with the UDP part. The problem I had was regarding the use of setsockopt. Because I test the code on a regular linux machine the lingering of the sockets after killing the application can be annoying. From what you describe below, SO_REUSEADDR should not be necessary for this case (did I get that correctly? ). SO_REUSEADDR is not implemented in RTnet. You should get an error when trying to apply that on an RT socket. Because I use the posix skin, and because it was necessary in regular linux, i started out using it in the common code base but I never managed to get it working in RT so I removed it again. I used something like: int reuseSetting = 1; setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, , sizeof(int); Or even (because I use both rt and not rt sockets in the same code and I got the feeling that the automatic handling of this didn't quite work out.) __cobalt_setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, , sizeof(int); This gave me: -- 70642.91] [Xenomai] switching App Thread to secondary mode after exception #14 in kernel-space at 0xa0281787 (pid 633) [70642.667326] BUG: unable to handle kernel paging request at 7fe06ff84d20 [70642.667948] IP: [] rt_ip_ioctl+0x27/0x120 [rtipv4] [70642.668566] PGD 8002631e7067 [70642.668575] PUD 24a07d067 [70642.669184] PMD 260cab067 [70642.669189] PTE 80023b6cc067 [70642.669805] [70642.670403] Oops: 0001 [#5] PREEMPT SMP [70642.670989] Modules linked in: rtudp rtipv4 intel_powerclamp intel_rapl coretemp rt_igb e1000e i915 rtnet pcan(O) video fan thermal_sys [70642.671629] CPU: 3 PID: 633 Comm: App Thread Tainted: G D W O 4.9.90-xeno-cobolt #1 [70642.672239] Hardware name: Default string Default string/SKYBAY, BIOS 5.0.1.1 04/18/2016 [70642.672854] I-pipe domain: Linux [70642.673459] task: 880263231b00 task.stack: c90001798000 [70642.674066] RIP: 0010:[] [] rt_ip_ioctl+0x27/0x120 [rtipv4] [70642.674683] RSP: 0018:c9000179bda8 EFLAGS: 00010246 [70642.675300] RAX: 0007 RBX: 40180021 RCX: 88026dd8 [70642.675923] RDX: 7fe06ff84d20 RSI: 40180021 RDI: 880262a86800 [70642.676544] RBP: c9000179bdd0 R08: 0050 R09: 880263231b00 [70642.677166] R10: 00e6 R11: R12: 880262a86800 [70642.677783] R13: 40180021 R14: 7fe06ff84d20 R15: 62a86800 [70642.678394] FS: 7fe06ff85700() GS:88026dd8() knlGS: [70642.679009] CS: 0010 DS: ES: CR0: 8005003b [70642.679621] CR2: 7fe06ff84d20 CR3: 000261678000 CR4: 00360630 [70642.680233] Stack: [70642.680838] a028c6f7 0001 81178cd0 880262a86800 [70642.681464] 0003 c9000179be60 811725be 0202 [70642.682086] 880263231b00 88020010 c9000179be70 c9000179be08 [70642.682711] Call Trace: [70642.683325] [] ? rt_udp_ioctl+0x67/0x8c [rtudp] [70642.683949] [] ? CoBaLt_fcntl+0x20/0x20 [70642.684573] [] rtdm_fd_ioctl+0xee/0x280 [70642.685199] [] ? CoBaLt_fcntl+0x20/0x20 [70642.685825] [] ? CoBaLt_fcntl+0x20/0x20 [70642.686445] [] CoBaLt_ioctl+0xe/0x20 [70642.687064] [] ipipe_syscall_hook+0x112/0x350 [70642.687686] [] __ipipe_notify_syscall+0xc8/0x190 [70642.688306] [] ipipe_handle_syscall+0x2a/0xb0 [70642.688925] [] do_syscall_64+0x2d/0xf0 [70642.689514] [] entry_SYSCALL_64_after_swapgs+0x58/0xc6 [70642.690073] Code: 68 b8 eb b0 e8 ab 04 66 e1 81 fe 27 00 10 40 0f 84 c1 00 00 00 7e 73 81 fe 20 00 18 40 74 3c 81 fe 21 00 18 40 0f 85 a0 00 00 00 <8b> 02 8b 4a 10 4c 8b 42 08 8b 72 04 85 c0 0f 85 d6 00 00 00 83 [70642.691405] RIP [] rt_ip_ioctl+0x27/0x120 [rtipv4] [70642.692026] RSP
Re: RTnet bind failed socket again
- Den 3 jun 2019, på kl 17:33, Jan Kiszka jan.kis...@siemens.com skrev: > On 03.06.19 11:10, Per Oberg via Xenomai wrote: > > - Den 3 jun 2019, på kl 11:06, xenomai xenomai@xenomai.org skrev: > >> Hi, > >> My program opens a RTnet socket successfully but the program gets killed > >> by a different issue that has nothing to do with this. However, the > >> RTnet socket is still bound. If I try to start the program again i get > >> the error "Address already in use". If it would be a normal unix socket > >> I would simply call it with SO_REUSEADDR but this is not possible with > >> RTnet from what I understand. >> I tried this and failed miserably. That said, I'm also interested in the >> answer > > to this question. > >> My question is why the socket is not unbound after the binding process > >> is killed and if there is a way to reclaim this socket. By the way, it > >> has to be this socket since the communication partner expects the server > >> to listen on this exact port. > >> Cheers, > >> Johannes > > Per Öberg > Are we talking about UDP in both cases? I use UDP, yes. But I had no problems with the UDP part. The problem I had was regarding the use of setsockopt. Because I test the code on a regular linux machine the lingering of the sockets after killing the application can be annoying. From what you describe below, SO_REUSEADDR should not be necessary for this case (did I get that correctly? ). Because I use the posix skin, and because it was necessary in regular linux, i started out using it in the common code base but I never managed to get it working in RT so I removed it again. I used something like: > int reuseSetting = 1; > setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, , > sizeof(int); Or even (because I use both rt and not rt sockets in the same code and I got the feeling that the automatic handling of this didn't quite work out.) > __cobalt_setsockopt(datagramSocket, SOL_SOCKET, SO_REUSEADDR, , > sizeof(int); This gave me: -- 70642.91] [Xenomai] switching App Thread to secondary mode after exception #14 in kernel-space at 0xa0281787 (pid 633) [70642.667326] BUG: unable to handle kernel paging request at 7fe06ff84d20 [70642.667948] IP: [] rt_ip_ioctl+0x27/0x120 [rtipv4] [70642.668566] PGD 8002631e7067 [70642.668575] PUD 24a07d067 [70642.669184] PMD 260cab067 [70642.669189] PTE 80023b6cc067 [70642.669805] [70642.670403] Oops: 0001 [#5] PREEMPT SMP [70642.670989] Modules linked in: rtudp rtipv4 intel_powerclamp intel_rapl coretemp rt_igb e1000e i915 rtnet pcan(O) video fan thermal_sys [70642.671629] CPU: 3 PID: 633 Comm: App Thread Tainted: G D W O 4.9.90-xeno-cobolt #1 [70642.672239] Hardware name: Default string Default string/SKYBAY, BIOS 5.0.1.1 04/18/2016 [70642.672854] I-pipe domain: Linux [70642.673459] task: 880263231b00 task.stack: c90001798000 [70642.674066] RIP: 0010:[] [] rt_ip_ioctl+0x27/0x120 [rtipv4] [70642.674683] RSP: 0018:c9000179bda8 EFLAGS: 00010246 [70642.675300] RAX: 0007 RBX: 40180021 RCX: 88026dd8 [70642.675923] RDX: 7fe06ff84d20 RSI: 40180021 RDI: 880262a86800 [70642.676544] RBP: c9000179bdd0 R08: 0050 R09: 880263231b00 [70642.677166] R10: 00e6 R11: R12: 880262a86800 [70642.677783] R13: 40180021 R14: 7fe06ff84d20 R15: 62a86800 [70642.678394] FS: 7fe06ff85700() GS:88026dd8() knlGS: [70642.679009] CS: 0010 DS: ES: CR0: 8005003b [70642.679621] CR2: 7fe06ff84d20 CR3: 000261678000 CR4: 00360630 [70642.680233] Stack: [70642.680838] a028c6f7 0001 81178cd0 880262a86800 [70642.681464] 0003 c9000179be60 811725be 0202 [70642.682086] 880263231b00 88020010 c9000179be70 c9000179be08 [70642.682711] Call Trace: [70642.683325] [] ? rt_udp_ioctl+0x67/0x8c [rtudp] [70642.683949] [] ? CoBaLt_fcntl+0x20/0x20 [70642.684573] [] rtdm_fd_ioctl+0xee/0x280 [70642.685199] [] ? CoBaLt_fcntl+0x20/0x20 [70642.685825] [] ? CoBaLt_fcntl+0x20/0x20 [70642.686445] [] CoBaLt_ioctl+0xe/0x20 [70642.687064] [] ipipe_syscall_hook+0x112/0x350 [70642.687686] [] __ipipe_notify_syscall+0xc8/0x190 [70642.688306] [] ipipe_handle_syscall+0x2a/0xb0 [70642.688925] [] do_syscall_64+0x2d/0xf0 [70642.689514] [] entry_SYSCALL_64_after_swapgs+0x58/0xc6 [70642.690073] Code: 68 b8 eb b0 e8 ab 04 66 e1 81 fe 27 00 10 40 0f 84 c1 00 00 00 7e 73 81 fe 20 00 18 40 74 3c 81 fe 21 00 18 40 0f 85 a0 00 00 00 <8b> 02 8b 4a 10 4c 8b 42 08 8b 72 04 85 c0 0f 85 d6 00 00 00 83 [70642.691405] RIP [] rt_ip_ioctl+0x27/0x120 [rtipv4] [70642.692026] RSP [70642.692642] CR2: 7fe06ff84d20 [70642.693250] ---[ end trace
Re: RTnet bind failed socket again
On 03.06.19 11:10, Per Oberg via Xenomai wrote: - Den 3 jun 2019, på kl 11:06, xenomai xenomai@xenomai.org skrev: Hi, My program opens a RTnet socket successfully but the program gets killed by a different issue that has nothing to do with this. However, the RTnet socket is still bound. If I try to start the program again i get the error "Address already in use". If it would be a normal unix socket I would simply call it with SO_REUSEADDR but this is not possible with RTnet from what I understand. I tried this and failed miserably. That said, I'm also interested in the answer to this question. My question is why the socket is not unbound after the binding process is killed and if there is a way to reclaim this socket. By the way, it has to be this socket since the communication partner expects the server to listen on this exact port. Cheers, Johannes Per Öberg Are we talking about UDP in both cases? What should happen: When a process dies, its open rt fds gets closed. RTDM will call down to the driver to do the necessary work, in case of UDP to rt_udp_close which also removes the entries from the port registry and bitmap. You can confirm that by tracing that part - or send a simple test case that reproduces the issue. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: RTnet bind failed socket again
- Den 3 jun 2019, på kl 11:06, xenomai xenomai@xenomai.org skrev: > Hi, > My program opens a RTnet socket successfully but the program gets killed > by a different issue that has nothing to do with this. However, the > RTnet socket is still bound. If I try to start the program again i get > the error "Address already in use". If it would be a normal unix socket > I would simply call it with SO_REUSEADDR but this is not possible with > RTnet from what I understand. I tried this and failed miserably. That said, I'm also interested in the answer to this question. > My question is why the socket is not unbound after the binding process > is killed and if there is a way to reclaim this socket. By the way, it > has to be this socket since the communication partner expects the server > to listen on this exact port. > Cheers, > Johannes Per Öberg
RTnet bind failed socket again
Hi, My program opens a RTnet socket successfully but the program gets killed by a different issue that has nothing to do with this. However, the RTnet socket is still bound. If I try to start the program again i get the error "Address already in use". If it would be a normal unix socket I would simply call it with SO_REUSEADDR but this is not possible with RTnet from what I understand. My question is why the socket is not unbound after the binding process is killed and if there is a way to reclaim this socket. By the way, it has to be this socket since the communication partner expects the server to listen on this exact port. Cheers, Johannes
