panicked at 'Removing an unknown connection' #61
Labels
Comments
|
Thank you for your report. Is it on the last release (2.1), or on the |
|
I fail to reproduce, and by reading the code, for now I can't think of any execution leading to remove an unknown connection. Does it always happen after a |
|
release 2.1 2017-11-30 11:03:43.102 ERROR TcpConnection: 10.0.0.2:50815 -> 13.107.3.128:443 Cannot read: [ConnectionReset] Удаленный хост принудительно разорвал существующее подключение. (os error 10054) |
|
In my program I will restart after an error. |
|
I'm developing a Windows service based on your software |
OK, the error log seems consistent. i will think about what the cause could be.
What do you mean? I did not understand. |
|
I again inattentive. Everything is already there: |
rom1v
added a commit
that referenced
this issue
Mar 6, 2018
In a single poll() result, the client may be ready to receive a packet from the device, that will be sent to a specific network connection, and in the same time that connection may be ready to send a packet to the client. There is a possibility that both events will lead to close the connection, and remove it from the router. In that case, the second removal did panic. Instead, remove it only if it does not exist. See: - <#61> - <#85>
|
Fixed on |
|
Running latest master (350e39b) on OS X 10.12.6 I get: |
It's fixed on |
|
Oops. Thanks! Now with |
|
...as well as these: |
rom1v
added a commit
that referenced
this issue
Mar 6, 2018
This reverts commit 10d5e32. This does not fix the root cause, so the panic still happens. <#61 (comment)>
|
Thank you @2Beaucoup, I reverted the patch. I need to reproduce it myself. How do you reproduce it often enough? |
|
@2Beaucoup If you can reproduce the problem easily, could you please test the Thank you :) |
|
Sure. :) |
|
Thank you. 👍 May I ask you to use different (for instance, the two Additional question: are there more logs containing |
|
Of course. I updated the output. Just ping if you need more. Thanks! |
|
Thank you very much. I located the issue, but don't understand it. In To simplify: let x = …;
let y = …;
println!("{:p} == {:p} ? {}", x, y, ptr::eq(x, y));It prints: This is scary. And for now, I failed to reproduce in a sample (the sample always works as expected). |
rom1v
added a commit
that referenced
this issue
Mar 6, 2018
Connection is a trait, so "*const Connection" is a fat pointer (128
bits, 64 bits pointing to the instance, 64 bits pointing to the vtable).
For some reason (a bug?), in Router::remove(), the connection passed as
argument has a vtable different from the (same) connection stored in the
"connections" field.
This has the unexpected consequence that for some x and y:
println!("{:p} == {:p} ? {}", x, y, ptr::eq(x, y));
prints:
0x7f87a8c3a618 == 0x7f87a8c3a618 ? false
Thus, the connection to remove was not found, leading to the panic
"Removing an unknown connection".
See <#61 (comment)>
Thank you to mbrubeck on IRC freenode/##rust, who helped a lot to
understand the issue.
|
Fixed by c36fa4d. My craziest Rust bug ever. |
|
Thanks a lot @2Beaucoup for your help. |
|
Nice! Will give it a try tomorrow. |
rom1v
added a commit
that referenced
this issue
Mar 6, 2018
Connection is a trait, so "*const Connection" is a fat pointer (128
bits, 64 bits pointing to the instance, 64 bits pointing to the vtable).
For some reason (a bug?), in Router::remove(), the connection passed as
argument has a vtable different from the (same) connection stored in the
"connections" field.
This has the unexpected consequence that for some x and y:
println!("{:p} == {:p} ? {}", x, y, ptr::eq(x, y));
prints:
0x7f87a8c3a618 == 0x7f87a8c3a618 ? false
Thus, the connection to remove was not found, leading to the panic
"Removing an unknown connection".
See <#61 (comment)>
Thanks to mbrubeck on IRC freenode/##rust, who helped a lot to
understand the issue.
rom1v
added a commit
that referenced
this issue
Mar 6, 2018
Connection is a trait, so "*const Connection" is a fat pointer (128
bits, 64 bits pointing to the instance, 64 bits pointing to the vtable).
For some reason (a bug?), in Router::remove(), the connection passed as
argument has a vtable different from the (same) connection stored in the
"connections" field.
This has the unexpected consequence that for some x and y:
println!("{:p} == {:p} ? {}", x, y, ptr::eq(x, y));
prints:
0x7f87a8c3a618 == 0x7f87a8c3a618 ? false
Thus, the connection to remove was not found, leading to the panic
"Removing an unknown connection".
Instead, compare only the data part, by casting the fat pointers to thin
pointers.
See <#61 (comment)>
Thanks to mbrubeck on IRC freenode/##rust, who helped a lot to
understand the issue.
rom1v
added a commit
that referenced
this issue
Mar 6, 2018
Connection is a trait, so "*const Connection" is a fat pointer (128
bits, 64 bits pointing to the instance, 64 bits pointing to the vtable).
For some reason (a bug?), in Router::remove(), the connection passed as
argument has a vtable different from the (same) connection stored in the
"connections" field.
This has the unexpected consequence that for some x and y:
println!("{:p} == {:p} ? {}", x, y, ptr::eq(x, y));
prints:
0x7f87a8c3a618 == 0x7f87a8c3a618 ? false
Thus, the connection to remove was not found, leading to the panic
"Removing an unknown connection".
Instead, compare only the data part, by casting the fat pointers to thin
pointers.
See <#61 (comment)>
Thanks to mbrubeck on IRC freenode/##rust, who helped a lot to
understand the issue.
|
works like a charm. :) |
|
FYI: these are the currently logged errors for a sample session: |
|
@2Beaucoup yes, the crash occurred after network socket errors. Now it does not crash anymore, but you still have network socket errors (your computer cannot connect to the requested server) :) |
This was referenced Mar 9, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
sometimes the program terminates with an error:
What is the reason for this?
The text was updated successfully, but these errors were encountered: