Re: sockets exn- one day i'll learn to put things down

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Firstly, lets add the record backtrace to the main function; very useful!

On the Lwt front, you are hitting the fact that the backtrace is lost between 
threads due to the Lwt monad. However, the pa_lwt syntax extension has an 
option to preserve the backtrace.  I haven't turned this on due to a certain 
difficulty with figuring out how to make it optional in ocamlbuild. 

However, I could just turn it on permanently, with us remembering to turn it 
off when doing performance tests for production runs, where thread backtrace 
recording may be too expensive.

Any objections to that?

On the general topic of debugging, what we really need is an interactive 
toplevel. Lwt itself has a fantastic one if you install the Debian package 
(lwt-toplevel) which could let you inspect the state of threads as it runs.  
This is something that could be ported to Mirage at some point... there's even 
a native code version of the toplevel now, so the Xen backend could get in on 
the party too!

Anil

On 1 Nov 2011, at 18:26, Richard Mortier wrote:

> ok- so i patently failed to get on and do some real work.  instead, continued 
> blundering my way through figuring out this occasional exception.  this is 
> something of a brain dump.
> 
> [[ cl-mirage: ocaml gods welcome to look at this! :)  i've no real idea what 
> i'm doing.  symptom is that, when running the mirage-tutorial on unix -- osx 
> to be precise -- after "some" page reloads, it fails with a fatal error 
> indicating an uncaught exception:
> 
> Fatal error: exception Invalid_argument("Lwt.wakeup")
> 
> ...any hints welcome; roughly how far i've managed to get is below...
> ]]
> 
> 1/ looks like cut'n'paste of c code unnecessary to get backtraces- following 
> patch appears to dtrt in terms of printing backtrace:
> 
> """
> : mort@greyjay:mirage.git$; git diff lib/os/unix/main.ml
> diff --git a/lib/os/unix/main.ml b/lib/os/unix/main.ml
> index 488d722..973d3ff 100644
> --- a/lib/os/unix/main.ml
> +++ b/lib/os/unix/main.ml
> @@ -69,6 +69,7 @@ let run t =
>   in
>   (* Register a callback for the JS runtime to restart this function *)
>   let _ = Callback.register "Main.run" fn in
> +  Printexc.record_backtrace true;
>   fn ()
> 
> let () = at_exit (fun () -> run (call_hooks exit_hooks))
> """
> ... unless you know of a reason why that actually gives plausible looking 
> garbage?
> 
> 2/ my current impression is that we're waking up a thread that isn't actually 
> asleep.  i'm basically clueless here - the exception appears to be being 
> thrown somewhere in std/format.ml and/or std/lwt.ml, eg.,
> 
> """
> [00009] 2011/10/01T16:33:32Z  info               Server: /slides.js 
> (backtrace: Raised at file "net/socket/channel.ml", line 129, characters 
> 16-121
> )
> Fatal error: exception Invalid_argument("Lwt.wakeup")
> Raised at file "std/format.ml", line 195, characters 15-26
> Called from file "std/format.ml", line 421, characters 8-33
> Called from file "std/format.ml", line 436, characters 6-24
> Called from file "std/lwt.ml", line 427, characters 66-71
> Re-raised at file "std/lwt.ml", line 485, characters 33-36
> Called from file "std/lwt.ml", line 147, characters 2-34
> Called from file "std/lwt.ml", line 147, characters 2-34
> ...many many repeats of line above...
> Called from file "std/lwt.ml", line 147, characters 2-34
> Called from file "std/lwt.ml", line 130, characters 8-15
> Called from file "std/lwt.ml", line 147, characters 2-34
> make: *** [run-socket_fs] Error 2
> """
> 
> the exn in channel.ml is the Closed exn raised to indicate file closure, and 
> correctly handled.
> 
> the exn in format.ml appears to come from parsing the format string, possibly 
> reaching the end.
> 
> after adding some extra debug output, the exn in lwt.ml is trying to wakup a 
> thread that's already in state "Return"
> 
> any suggestions?
> 
> 3/ in general, is there a well-known good setup for debugging this stuff?  
> useful compiler flags?  useful pretty printer functions for getting state out 
> on the console?
> -- 
> Cheers,
> 
> R.
> 
> This message and any attachment are intended solely for the addressee and may 
> contain confidential information. If you have received this message in error, 
> please send it back to me, and immediately delete it.   Please do not use, 
> copy or disclose the information contained in this message or in any 
> attachment.  Any views or opinions expressed by the author of this email do 
> not necessarily reflect the views of the University of Nottingham.
> 
> This message has been checked for viruses but the contents of an attachment
> may still contain software viruses which could damage your computer system:
> you are advised to perform your own checks. Email communications with the
> University of Nottingham may be monitored as permitted by UK legislation.