Arc Forumnew | comments | leaders | submitlogin
3 points by waterhouse 2165 days ago | link | parent

It should be possible to get the continuation from the point of failure and the dynamic variables from the failing thread (basically: the stack), the same information from any other running threads, and the set of global variables (this at least can be gotten with (namespace-mapped-symbols)), and trace the graph of reachable objects from there, and serialize it all to a file. I don't know if Racket provides the ability to do all that, though; for one thing, I don't know if there's a way to access the variables saved in a closure (from outside the closure).[1] (Maybe using unsafe operations could do that.) Since tracing the graph of objects is exactly what a GC does, and a proper moving GC has to be able to learn the type of every object and where all the pointers are, it must have that functionality, whether or not it's exposed. (I think it should be exposed, of course.)

Barring that, it's possible that the gdbdump rocketnia points at is the easiest way to do it in Racket.

Also, I guess if you're using the FFI at all (which, say, any GUI program would do), then you do need the full core dump if you want to get the state of the C libraries you're using.

[1] https://docs.racket-lang.org/reference/procedures.html isn't promising. https://docs.racket-lang.org/web-server-internal/closure.htm... provides wrapper macros to make serializable lambdas, implying that there is no way to serialize normal lambdas, which is unfortunate.