search

trifork / erjang

A JVM-based Erlang VM
http://www.erjang.org
Apache License 2.0
726 stars 62 forks source link

erlang:check_process_code not implemented #20

Open krestenkrab opened 14 years ago

krestenkrab commented 14 years ago

This is a rather challenging problem, but I think that we can make an approximation. We need to have some logic implemented in Kilim to get a real stack trace (with class references) for another Kilim process. kilim.Task.getStackTrace() -> java.lang.Class[], which must work for processes that are both running, and processes that are dormant. For now, the implementation of erlang:check_process_code simply returns true.

edwardw commented 13 years ago

Trying to attack the problem. Two things stand out so far. One is that current implementation seems to get semantic of erlang:delete_module/1 wrong and doesn't implement erlang:purge_module/1 at all. This should be relatively easier to fix.

Then the hard part. To implement erlang:check_process_code/2, I need to go through the stack frame of given erlang process. The closest thing I can manage is EProc.stack, but that's only for interpreted mode. Maybe the answer lies in kilim.Fiber.

krestenkrab commented 13 years ago

OK, so to get the real (erlang) stack frames, you need to extend the mechanism by which we also kill erlang processes. (all processes calls ETask.check_kill() periodically [before msg send/receive, and on backwards branches]) That hook needs to be extended with a mode that can capture a stack trace (add a process flag STATE_STACK_TRACE, which will generate a stack trace, send it somewhere, and clear the state back to what is was before). That is basically the only way to do it.

To generate a stack trace you can just do (new ErlangException()).getTrace() within that hook I am talking about.

To wake up a given EPID, do epid.task().resume() . Anywhere a process is waiting for a condition (like a message receive) it should just spin around and sleep itself again, so nothing should be hurt by waking processes any time.

So, it's a bit hairy. but doable ... messing with the process state i ETask is the most likely thing to cause trouble ... if you try to do this while the process is in the initializing or dying states... I can imagine things going wrong.

edwardw commented 13 years ago

Ran with your suggestion. I can go through stack frames of given EPID now. If a stack frame has a reference to EModule in question, erlang:check_process_code/2 can happily return true. But if a frame has an EFun in it and that EFun has a function reference as one of its arguments, I have to check that function reference, too. I.e., besides stack frames, I also need actual arguments for each frame.

Mission impossible? Or doable by hacking kilim?

krestenkrab commented 11 years ago

@edwardw do you still have that code lying around somewhere?

edwardw commented 11 years ago

@krestenkrab Unfortunately, no. I've had a new laptop for a while and that snippet of code has been long gone. Also sorry for the late reply; I didn't notice the github notification for your latest comment.

krestenkrab commented 11 years ago

I've done some work related to this here: https://github.com/trifork/erjang/commit/cb9304b08c9704f2a0bec8812327ff300f6919e1