got error "Module is not interpreted, can't set breakpoints." after interpreting

[richcarl]

From http://code.google.com/p/distel/issues/detail?id=20

Reported by [email protected], Oct 29, 2009

What steps will reproduce the problem?

• compile with debug info
  (emacs@f11)> c(test, debug_info).

• distel connect to node emacs@f11 ( C-c C-d n )

(emacs@f11)5> i().
....
<0.31.0> erlang:apply/2 1597 4850
0
shell:shell_rep/4 17
<0.32.0> kernel_config:init/1 233 42
0
gen_server:loop/6 9
<0.33.0> supervisor:kernel/1 233 57
0
kernel_safe_sup gen_server:loop/6 9
<0.36.0> erlang:apply/2 2584 28119
0
rpc:local_call/3 49
Total 28903 761511
0

271

• distel reload erlang module test ( C-c C-d L)
  now I am seeing distel in i() output

(emacs@f11)6> i().
... ...
<0.33.0> supervisor:kernel/1 233 57
0
kernel_safe_sup gen_server:loop/6 9
<0.36.0> erlang:apply/2 2584 40333
0
rpc:local_call/3 49
<0.46.0> inet_tcp_dist:do_accept/6 610 516
0
dist_util:con_loop/9 11
<0.50.0> distel:gl_proxy/1 233 1
0
'distel_gl_for_<8785. distel:gl_proxy/1 4
Total 28992 812442
0
286
ok

• Toggle debug interpreting of the module ( C-c C-d i)
  got messsage : Interpreting: test
  got distel:debug_subscriber* in i() output

(emacs@f11)7> i().

... ...
<0.46.0> inet_tcp_dist:do_accept/6 987 803
0
dist_util:con_loop/9 11
<0.50.0> distel:gl_proxy/1 233 1
0
'distel_gl_for_<8785. distel:gl_proxy/1 4
<0.53.0> distel:debug_subscriber_init/2 233 37
0
distel:debug_subscriber/1 5
<0.55.0> dbg_iserver:init/1 377 104
0
dbg_iserver gen_server:loop/6 9
Total 29945 901441
0
303

• Toggle a breakpoint at current line ( C-c SPC)
  got messsage : Module is not interpreted, can't set breakpoints.
  i() output doesn't change much.

  When distel worked before, it showed two new process
  distel:attach_init/2, distel:attach_loop/1, but now it doesn't:

(emacs@f11)8> i().
... ...

<0.46.0> inet_tcp_dist:do_accept/6 987 1248
0
dist_util:con_loop/9 11
<0.50.0> distel:gl_proxy/1 233 1
0
'distel_gl_for_<8785. distel:gl_proxy/1 4
<0.53.0> distel:debug_subscriber_init/2 233 37
0
distel:debug_subscriber/1 5
<0.55.0> dbg_iserver:init/1 377 104
0
dbg_iserver gen_server:loop/6 9
Total 30322 967176
1

distel:functions(io, "").
{ok,["columns","format","fread","fwrite","get_chars",
"get_line","get_password","getopts","nl","parse_erl_exprs",
"parse_erl_form","put_chars","read","request","requests",
"rows","scan_erl_exprs","scan_erl_form","setopts","write"]}

distel:functions(rpc, "").
{ok,["abcast","async_call","block_call","call","cast",
"code_change","eval_everywhere","handle_call","handle_cast",
"handle_info","init","multi_server_call","multicall",
"nb_yield","parallel_eval","pinfo","pmap",
"proxy_user_flush","safe_multi_server_call","sbcast",
"server_call","start","start_link","stop","terminate",
"yield"]}

What is the expected output? What do you see instead?

got error "Module is not interpreted, can't set breakpoints." after
interpreting

What version of the product are you using? On what operating system?

GNU Emacs 23.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.16.5)
of 2009-08-03 on x86-4.fedora.phx.redhat.com

Erlang R13B02 (erts-5.7.3) [source] [64-bit] [smp:2:2] [rq:2] [async-
threads:0] [hipe] [kernel-poll:false](trying Erlang R12 also get the same result of interpret error)

Linux Fedora release 11: fc11.x86_64

URL: http://distel.googlecode.com/svn/trunk
Repository Root: http://distel.googlecode.com/svn
Repository UUID: d5f8e727-742a-0410-b67d-dd739a6cc792
Revision: 93
Node Kind: directory
Schedule: normal
Last Changed Author: lukego
Last Changed Rev: 93
Last Changed Date: 2009-08-02 16:38:33 -0700 (Sun, 02 Aug 2009)

Please provide any additional information below.

I tried reload and interpret the module multiple times and also switched to
erlang R12, still got the same result.

I tried to connect to a erlang node outside of emacs, emacs showed a popup
windows "Attach debugger to xyz@f11 instead of emacs@f11" when
intrepreting, still got the same error "Module is not interpreted, can't
set breakpoints."

Comment 1 by project member [email protected], Nov 3, 2009

I only occasionally reproduce this :<
There is a workaround;
C-c C-d m (opens the monitor buffer)
k (kills the monitor buffer)
C-c C-d i (start interpreting) in the .erl buffer will now work.

Status: Accepted
Owner: mats.cronqvist
Comment 2 by [email protected], Nov 14, 2009

I have exactly same problem on:

MacOSX 10.6 (Snow Leopard),
Erlang 13B02,
Emacs 22 (Carbon) or Emacs 23 (cocoa).

Comment 3 by [email protected], Dec 26, 2009

I've set a breakpoint and did some debugging with r64 from trunk, although it may be
not the last rev where debugging is still working.
You can check out this rev with
% svn checkout -r 64 http://distel.googlecode.com/svn/trunk distel-r64

I followed instructions in http://bc.tech.coop/blog/070528.html.
Also, I had to fix install path in Makefile:

--- a/Makefile
+++ b/Makefile
@@ -10,7 +10,7 @@ infodir = ${prefix}/info
erlc = erlc
emacs = emacs

-ELISP_DIR = ${datadir}/${emacs}/site-lisp/distel
+ELISP_DIR = ${datadir}/distel/elisp
EBIN_DIR = ${datadir}/distel/ebin
ERL_SRC_DIR = ${datadir}/distel/src

Comment 4 by [email protected], Jan 24, 2010

I'm having this problem, also, and it's 100% of the time, not intermittent. However,
the work around posted above seems to work.

Comment 5 by [email protected], Jan 24, 2010

If there's anything I can do to help troubleshoot this, let me know:
[email protected]. Even pointing me in the direction of things to look at would
be helpful.

Also, it'd be cool if the official repo for this were moved to github, like the
official erlang repo was. I think you might get a little more help, e.g., I'd be much
more likely to submit patches.

Comment 6 by project member [email protected], Jan 25, 2010

I believe there's a race condition in the interpreter init code (on the emacs side).
hairy stuff, unfortunately...

I agree a move to github would be a good thing. just need to reach my mental tipping
point...

[LMMilewski]

Simplest way to solve this is to use C-cC-dm to show process manager and kill it with k immediately. Then start debugging again - everything should work.