<div dir="ltr">Hi Siri!<div><br></div><div>You are right. I had a modification on the actual code_server.erl, which I hadn't removed when generating the previous report. With a clean R17 I cannot reproduce it so apologies for the false alarm.<div>
<br></div><div>Back to the main topic, this sequence does not seem to work either, as the code_server is still stuck in old code:</div></div><div><div><br></div><div>~$ diff ~/git/otp/lib/kernel/src/code_server.erl ~/code_server.erl </div>
<div>1263a1264</div><div>> erlang:display(foo),</div></div><div>~$ erlc code_server.erl</div><div>~$ erl -nostick<br></div><div><div>Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]</div>
<div><br></div><div>Eshell V6.0 (abort with ^G)</div><div>1> l(code_server).</div><div>{module,code_server}</div><div>2> code:which(code_server).</div><div>"/home/stavros/code_server.beam"</div><div>3> erlang:check_old_code(code_server).</div>
<div>true</div><div>4> code:soft_purge(code_server).</div><div>false</div><div>5> erlang:check_process_code(whereis(code_server),code_server).</div><div>true</div><div>6> sys:suspend(code_server).</div><div>ok</div>
<div>7> sys:change_code(code_server, code_server, ignored, ignored).</div><div>ok</div><div>8> sys:resume(code_server).</div><div>ok</div><div>9> erlang:check_process_code(whereis(code_server),code_server).</div>
<div>true</div><div><br></div></div><div>Regards,</div><div><br></div><div>Stavros</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 27, 2014 at 1:31 PM, Siri Hansen <span dir="ltr"><<a href="mailto:erlangsiri@gmail.com" target="_blank">erlangsiri@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi Stavros!</div><div class="gmail_extra"><br><div class="gmail_quote">2014-06-23 11:48 GMT+02:00 Stavros Aronis <span dir="ltr"><<a href="mailto:aronisstav@gmail.com" target="_blank">aronisstav@gmail.com</a>></span>:</div>
<div class="gmail_quote"><div class=""><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div>a lot of time has passed indeed, and I have put in place a different kind of instrumentation, which works for what I want to do. Unfortunately I currently don't have the time to test again, but I suspect that the issue remains, for the reasons I explained.</div>
</div></blockquote><div><br></div></div><div>Yes, I assume nothing has changed - my point was that when receiving a change_code system message, code_server does a qualified call to system_code_change. This is where the actual code change is expected to happen - not in the call to system_continue at line 184.</div>
<div><br></div><div>I would think that the reason that sys uses a qualified call is that the module in question is not ?MODULE, but rather a callback.</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>Here is another bug, admittedly unrelated (since I am not trying to update the code of the code_server *process*):</div><div><br></div><div>1) Copied code_server.erl to my home directory and added an "erlang:display(foo)" call before the single erlang:load_module/1 call in the module.</div>
<div>2) Run the following:</div><div><div>$ erlc code_server.erl </div><div>$ erl -nostick</div><div>Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]</div><div><br>
</div><div>Eshell V6.0 (abort with ^G)</div><div>1> l(code_server).</div><div>{module,code_server}</div><div>2> code:which(code_server).</div><div>"/home/stavros/code_server.beam"</div><div>3> erlang:check_old_code(code_server).</div>
<div>true</div><div>4> code:soft_purge(code_server).</div><div>true</div><div>5> l(te *TAB*</div><div>Crash dump was written to: erl_crash.dump</div><div>Internal error: Invalid reference count found on #Fun<code_server.0.416>: About to erase fun still referred by code.</div>
<div>Aborted</div></div><div><br></div><div>I would expect the soft_purge to fail and the system not to crash.</div></div></blockquote><div><br></div></div><div>Yes, I would also expect that. And I can not reproduce the problem :(</div>
<div class="">
<div><br></div><div>$ erlc code_server.erl </div><div>$ erl -nostick</div></div><div>Erlang/OTP 17 [erts-6.0] [source-07b8f44] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]</div><div class=""><div><br></div><div>
Eshell V6.0 (abort with ^G)</div>
<div>1> l(code_server).</div><div>{module,code_server}</div><div>2> code:which(code_server).</div></div><div>"/home/siri/code_server.beam"</div><div class=""><div>3> erlang:check_old_code(code_server).</div>
<div>true</div>
<div>4> code:soft_purge(code_server).</div></div><div>false</div><div><br></div><div>I also have<br>5> erlang:check_process_code(whereis(code_server),code_server).</div><div>true</div><div><br></div><div>Do you have any other patches, or is it a plain 17.0? (Sorry - I don't have any other ideas right now :( )</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>/siri</div></font></span><div class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div></div><div><div><div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Jun 19, 2014 at 11:26 AM, Siri Hansen <span dir="ltr"><<a href="mailto:erlangsiri@gmail.com" target="_blank">erlangsiri@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Hi Stavros, I'm sorry for the very long delay! Are you still struggling with this problem or did you find a way around it? Would a code_change system message while the process is suspended possibly solve the problem?<div>
Regards</div><div>/siri</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-10 23:02 GMT+01:00 Stavros Aronis <span dir="ltr"><<a href="mailto:aronisstav@gmail.com" target="_blank">aronisstav@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr">Hello!<div><br></div><div>I am playing around with code instrumentation and trying to hack the code server so that it applies some transformation whenever it loads *any* module. The hack itself is relatively simple:</div>
<div><br></div><div>1) Instrument and reload any already loaded modules (come to think about it, during this process more modules may be loaded, but let's assume a fixpoint). This is to avoid the case where in order to load A, you have to instrument A, and the instrumenter itself needs a call to X, which is not yet loaded so you have to load X, so you have to instrument X, etc...</div>
<div>2) Get the Core Erlang code of the codeserver and wrap the second argument of erlang:load_module (Line 1264) with a call to my instrumenter (which is a function from binary() -> binary())</div><div>3) Load the patched code_server code</div>
<div>4) Move the code_server process from the old code to the new one.</div><div><br></div><div>I am having trouble with the last step. As far as I understand it, the reason is that the call to system_continue (Line 184) is not qualified, as is the similar call in sys.erl (Line 324).</div>
<div><br></div><div>Is there a reason why this is so? Is there any possibility for this to be patched?</div><div><br></div><div>Cheers,</div><div><br></div><div>Stavros</div><div><br></div></div>
<br></div></div>_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org" target="_blank">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div><br></div></div>
</blockquote></div><br></div>