-
Notifications
You must be signed in to change notification settings - Fork 15
regression: exception End_of_file #39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'm able to trigger this with a simple invocation of |
nice! so how did that pass QA ;) |
I notice there don't seem to be any tests in this repo... |
I guess the error from 1.4.1 is coming from:
The corresponding code in 1.6.0 is:
Arguably, the new code is correct. An unhandled async exception from the application should be handled by the application's handler (Lwt default: crash with stack trace), not hard-coded as a print statement in mirage-net-xen. |
@talex5 I agree -- but unless someone digs into whatever causes the exception, I'd prefer to retain the behaviour, at least between minor versions. From a deployment point of view this makes a huge difference. |
As a work-around, you can set |
On balance, I think it would be better to log these errors in tcpip. That can provide more context about the problem (e.g. |
Note: this issue made the deployement of mirage-www impossible with latest versions of mirage-net-xen. I'm pinning to 1.4.2. |
it is likely be mirage-http which throws |
I'll change it to log then. |
Since version 1.5 we've been passing exceptions to the user's Lwt exception handler rather than printing to the console. It seems that several users decided to stay with 1.4 rather than configure a handler. This patch uses the new logging support to log an error and continue. In addition, it also dumps out the frame that caused the crash. Closes mirage#39
my opinion on this is that the catch shouldn't be there... but in order to do that we should fix up all libraries up the stack which we have under control, then make releases (and at the same time, adjust [mirage-net-unix])https://github.com/mirage/mirage-net-unix/blob/ddb6d03893145309fa49f58a65298eb8c4fb1f24/lib/netif.ml#L126) to behave in the same way). since tcpip etc. do not directly depend on mirage-net-xen, I believe the safest is to use a mirage-types release for that (maybe the one where we switch to proper error handling?) [and related to the errors in https://github.com/mirage/mirage-net-xen/commit/6b1687c866eed9c23a239b2cdc7c32a4bc01bc33]... |
I don't think changing types helps here. The listen callback isn't supposed to return an error, so the type is already correct. The only choice is how to handle a bug in the callback function:
I'm happy with the behaviour in this PR. |
the type is correct, yes. I was thinking of using the mirage-types version to denote conflicts (for changes in behaviour) EDIT: I'd prefer to not have any |
|
Before, these were passed back to the network driver. However, tcpip is in a better position to report useful information. Example: [ERROR] uncaught exception accepting new TCP flow on port 80: (Failure "Test exception") See: mirage/mirage-net-xen#39
while mirage-net-xen=1.4.1 ouputs:
mirage-net-xen=1.6.0 (and likely 1.5.0) outputs:
and kills the unikernel hard... to reproduce, this is a unikernel serving a HTTP website and force-reloading it from the browser...
The text was updated successfully, but these errors were encountered: