Skip to content

erlang:check_process_code not implemented #20

Open
krestenkrab opened this Issue Mar 4, 2010 · 6 comments

2 participants

@krestenkrab
Trifork member

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
edwardw commented Jun 22, 2011

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
Trifork member

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
edwardw commented Jun 23, 2011

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
Trifork member

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

@edwardw
edwardw commented Sep 13, 2013

@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
Trifork member

I've done some work related to this here: cb9304b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.